9 research outputs found

    XML templates for constraints (XTC): um nível de abstracção para linguagens de especificação de restrições

    Get PDF
    Os DTDs permitem etiquetar um texto e validar a sua estrutura contra uma gramática. As linguagens de especificação de restrições (XML Constraint Specification Languages), nomeadamente o XCSL, o Schematron e os XML-Schemas, num nível mais elevado, já permitem validar aspectos não estruturais dos documentos XML, tais como: relações entre elementos, ou atributos, pertencentes a diferentes contextos; invariantes sobre modelos de dados; e restrições ao valor dos elementos, ou atributos. O sistema XCSL (XML Constraint Specification Language) nasceu no seio do nosso grupo de investigação [7]. No entanto esta linguagem foi testada em pé de igualdade com Schematron e XML-Schema. Usou-se um conjunto considerável de casos de estudo para testar e comparar estas três linguagens em termos: dos tipos de restrições especificáveis; da facilidade de aprendizagem/utilização; da informação devolvida ao utilizador. Os resultados mais significativos foram descritos em [3]. Fazendo esta comparação, apercebemo-nos que em cada linguagem e para cada tipo de restrição há um texto fixo e um conjunto de partes variáveis, sendo este último comum às várias linguagens. Tendo em conta estas partes variáveis, criámos templates para cada tipo de restrição, em cada uma das três linguagens. Com estes templates é possível gerar a especificação de restrições, em qualquer uma daquelas linguagens, a partir de um conjunto finito de parâmetros. Neste artigo mostramos os templates para cada par tipo-de-restrição/ linguagem. A partir das partes comuns desses templates construímos um conjunto de templates genéricos, designado XTC—XML Templates for Constraints—, um para cada tipo de restrição independentemente da linguagem escolhida. Com um documento XTC pode gerar-se todos os ficheiros de especificação de restrições, ou seja, um ficheiro de especificação para cada linguagem. Apresentamos, então, vários exemplos escritos em XTC. A implementação final usa aquilo a que chamamos sistema de folhas de estilo XSL de terceira geração, três níveis de folhas de estilos. Com a primeira folha de estilos (a do XTC) e o documento XTC geramos o documento de especificação na linguagem pretendida; com este último e a segunda folha de estilos (específica da linguagem pretendida) geramos a terceira folha de estilos (documento com o qual já se vai poder validar a semântica das várias instâncias); por fim, aplicamos esta última folha de estilos aos vários documentos da família em estudo. Terminamos o artigo mostrando como construímos esta arquitectura baseada apenas em XML e XSL

    XML and semantic validation

    Get PDF
    With XML as with SGML, we can have structural correctness, once they provide syntactic rules to state how to mark-up all the documents of the same family (of the same type); moreover, XML also imposes a working approach in which there is a complete separation between the structure of the data and the way it looks. So it is possible to avoid that someone will write a letter putting the ending before the body. Also, being purely declarative and completely independent of the processing, it is possible to swap documents between different systems without having to change them. But even this way, there still is a lack of content validation. Therefore, as Ramalho et al. pointed out, if a document has the decrees published by some kings, and includes their birth dates, it is critical if there is a sentence in which a king is said to publish a decree before he was born. In this paper we are concerned about reaching a way to automatically process a document in order to validate it semantically, avoiding this kind of incongruences that may spoil all a teams work

    Constraint specification languages: comparing XCSL, Schematron and XML-Schemas

    Get PDF
    After being able to mark-up text and validate its structure according to a grammar, we may start thinking it would be natural to be able to validate some non-structural issues in XML documents like relationships between elements belonging to different contexts, invariants over data models, constraints over attribute values and relationships between attributes. XML Schemas are a big step in that direction. However, they only allow users to specify primitive constraints like data typing and data format. Currently, we can find two approaches that represent a complement to DTDs or XML Schemas - XCSL and Schematron - and allow us to specify constraints and to validate the instances of a family of documents against that set of rules. Both are implemented on top of XSL. Both use a kind of an XML envelope to hide XSL specification. XSLT pattern language is the core language of both systems. With all these resemblances it is easy to conclude that they are quite similar. However they differ in some fundamental concepts. These two constraint specification languages together with XML Schemas were hardly tested and benchmarked with an huge test suite. The most significant results will be discussed in this paper. We will try to answer questions like: Do they do the same job? Are there some kind of constraints that are easier to specify with one of them? Do you need different background to use the tools? Is it possible to use them in similar situations (the same DTD, the same XML instances)? May we use them to produce an equal result? How do XCSL and Schematron relate to XML Schemas? What is the intersection area of these three? What kind of constraints each one of these three is able to specify? What kind of constraints each one of these three can not specify? In this article, we will use that test suite and show, step-by-step, the way we handled several kinds of constraints in many different instances.IDEAllianc

    XCSL tutorial

    Get PDF
    XML brought the concept of well-formmedness to the world of structured documents. An XML document can be well-formed or valid. To be valid it just has to convey certain rules specified in a DTD or XML Schema. DTDs enable us to specify structure rules and a little bit of dynamic semantics. Additionally, XML Schemas enable us to specify some static semantics. However, there are applications where we need to specify more complex invariants or constraints. Some of these constraints are structural but many of them are non-structural and have some degree of complexity. Here is where XCSL comes into scene, enabling to specify this extra semantics. This tutorial presents an XML based architecture that enables the specification of constraints, the kind of constraints we can not specify with DTDs. XCSL is not just a language, it is also a processing model. We also discuss the general philosophy underlying the proposed approach, presenting the architecture of our semantic validation system, and we detail the respective processor. To illustrate the use of the XCSL language and the subsequent processing, we present a complete case-study showing, step-by-step, the way we handled the various problems it raises. By making the analysis of this casestudy and following the explanation, it should be easy to use XCSL with every family of documents one comes across

    XCSL: XML constraint specification language

    Get PDF
    After being able to mark-up text and validate its structure according to a document type specification, we may start thinking it would be natural to be able to validate some nonstructural issues in the documents. This paper is to formally discuss semantic-related aspects. In that context, we introduce a domain specific language developed for such a purpose: XCSL. XCSL is not just a language, it is also a processing model. Furthermore, we discuss the general philosophy underlying the proposed approach, presenting the architecture of our semantic validation system, and we detail the respective processor. To illustrate the use of XCSL language and the subsequent processing, we present two case-studies. Nowadays, we can find some other languages to restrict XML documents to those semantically valid - namely Schematron and XML-Schema. So, before concluding the paper, we compare XCSL to those approaches

    Bidirectional conversion between XML documents and relational data bases

    No full text
    Relational databases have been used as support to the information storage since a long time ago. Maintenance and the natural growing of information systems imply the reuse of existing databases but, many times, information is not stored on the most convenient structure or in the desired platform; then it becomes necessary to export it into another system or to transform its structure. These tasks should be executed in a fast and safe way, and as much automatized as possible. In the last years, XML was accepted as the neutral format for information representation. This is due, mainly, to two factors. On one hand, XML documents are purely textual files, structured and independent of any hardware or software platforms. On the other hand, more and more public domain tools are available, to help users transforming XML documents. The paper focus on the use XML as an interchange format between database management systems and presents an XML language, DBML, that allows the definition of the structure and the content of a relational database. It also introduces a methodology to convert a database into a DBML document and two tools that allow transforming DBML documents, into SQL and back. DBML and the two conversion functions (dbsql2dbml and dbml2dbsql) provided the basis to support the idea of designing a language to specify database transformations and developing a generator to automatically produce the transference processors; we finish the paper with the proposal of such a system.(undefined

    Characterisation of microbial attack on archaeological bone

    Get PDF
    As part of an EU funded project to investigate the factors influencing bone preservation in the archaeological record, more than 250 bones from 41 archaeological sites in five countries spanning four climatic regions were studied for diagenetic alteration. Sites were selected to cover a range of environmental conditions and archaeological contexts. Microscopic and physical (mercury intrusion porosimetry) analyses of these bones revealed that the majority (68%) had suffered microbial attack. Furthermore, significant differences were found between animal and human bone in both the state of preservation and the type of microbial attack present. These differences in preservation might result from differences in early taphonomy of the bones. © 2003 Elsevier Science Ltd. All rights reserved
    corecore