9 research outputs found
XML templates for constraints (XTC): um nível de abstracção para linguagens de especificação de restrições
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
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
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
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
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
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
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