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

Proposta de nova metodologia para o cálculo do fator de sombreamento de vãos envidraçados por elementos horizontais

O comportamento térmico dos edifícios depende, em larga medida, dos ganhos solares verificados através dos vãos envidraçados. Devem os ganhos solares ser otimizados, isto é, durante a estação de aquecimento, os ganhos solares úteis devem ser maximizados e, durante a estação de arrefecimento, as cargas térmicas devidas aos ganhos solares devem ser minimizadas. Os dispositivos de sombreamento dos vãos envidraçados, devem, tanto quanto possível, provocar o sombreamento dos vãos, durante a estação de arrefecimento e, na medida do possível, não o provocar durante a estação de aquecimento. As palas horizontais para sombreamento de vãos envidraçados são particularmente adequadas a vãos orientados a sul. As palas devem ser dimensionadas de forma a, tanto quanto possível, provocarem o sombreamento dos vãos envidraçados durante a estação de arrefecimento sem que tal aconteça durante a estação de aquecimento. No entanto, verifica-se que, de uma forma geral, segundo a metodologia de cálculo prevista pelo Regulamento das Caraterísticas de Comportamento Térmico dos Edifícios (RCCTE), a existência de palas horizontais de sombreamento é penalizadora da eficiência energética dos edifícios. Com a presente comunicação, é apresentada uma nova metodologia de cálculo do factor de sombreamento por elementos horizontais. Através desta metodologia, desde que as palas horizontais sejam adequadamente dimensionadas, a sua existência originará necessidades nominais globais de energia primária de um edifício (Ntc) com um valor inferior ao que se obteria se não existissem as referidas palas. Consequentemente, a introdução de palas de sombreamento convenientemente dimensionadas contribuirá para a obtenção de uma mais elevada classe de eficiência energética do edifício

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

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: 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

Relatório de Estágio

O presente relatório tem como finalidade demonstrar todo o conhecimento adquirido e as atividades que fiz ao longo dos seis meses de estágio na produtora Bando à Parte, tendo como efeito terminar o 2º ciclo de estudos do curso de Cinema da Universidade da Beira Interior. As tarefas que fiz ao longo deste estágio foram bastante diversificadas, o que demonstra, desde logo, não só a versatilidade nos diferentes trabalhos, como também a capacidade de polivalência em diversas áreas, das quais destaco, assistência em realização, eletricista, anotação, montagem e som, para além destas, fiz também realização e fui operador de câmara. Com estas atividades pretendo, não só descrevê-las ao longo deste relatório, como também demonstrar que nós, alunos académicos, não temos obrigatoriamente que traçar uma só atividade para a nossa vida profissional, podemos escolher ser polivalentes e isso permitir-nos uma maior abertura do mercado de trabalho significando mais oportunidades, assim como, nos dará uma maior consciência de outras atividades do mesmo ramo, ao saber o que vindicar de cada área, resultando num trabalho menos dispendioso para as empresas e, a meu ver, com mais qualidade

XTche : a language for topic maps schema and constraints

This paper describes the design of a new language to formally specify constraints over Topic Maps. This language allows to express contextual conditions on classes of Topic Maps and the corresponding processing syntem. With XTche, a topic map designer defines a set of restrictions that enables to verify if a particular topic map is semantically valid. As the manual checking of large topic maps (frequent in real cases) is impossible, it is mandatory to provide an automatic validator. The constraining process presented in this paper is composed of a language and a processor. The language is based on XML Schema syntax. The processor is developed in XSLT language. The XTche processor takes a XTche specification and it generates a particular XSLT stylesheet. This stylesheet can validate a specific topic map (or a set of them) according to the constraints in the XTche specification. In this paper we will show, in abstract terms and with concrete examples, how to specify Topic Maps schemas and constraints with XTche

Algebraic specification of documents

According to recent research, nearly 95 percent of a corporate information is stored in documents. Further studies indicate that companies spent between 6 and 10 percent of their gross revenues printing and distributing documents in several ways: web and cdrom publishing, database storage and retrieval and printing. In this context documents exist in some different formats, from pure ascii files to internal database or text processor formats. It is clear that document reusability and low-cost maintenance are two important issues in the near future. The majority of available document processors is purpose-oriented, reducing the necessary flexibility and reusability of documents. Some waste of time arises from adapting the same text to different purposes. For example you may want to have the same document as an article as a set of slides or as a poster; or you can have a dictionnary document producing a book and a list of words for a spell-checker. This conversion could be done automatically from the first version of the document if it complies some standard requirements. The key idea will be to keep a complete separation between syntax and semantics. In this way we produce an abstract description separating conceptual issues from those concerned with the use. This note proposes a few guidelines to build a system to solve the above problem. Such a system should be an algebraic based environment and provide facilities for: - Document type definitions; - Definition of functions over document types; - Document definitions as algebraic terms. This approach (rooted in the tradition of constructive algebraic specification), will allow for homogeneous environment to deal with operations such as merging documents, converting formats, translating documents, extracting different kinds of information (to set up information repositories, data bases, or semantic networks) or portions of documents (as it happens, for instance, in literate programming), and some other actions, not so traditional, like mail reply, or memo production. We intend to use CAMILA (a specification language and prototyping environment developed at Universidade do Minho, by the Computer Science group) to develop the above mentioned system

Metamorphosis: an environment to achieve semantic interoperability with topic maps

Nowadays, data handled by an institution or company is spread out by more than one database and lots of documents of different types. To extract the information implicit in that data, it is necessary to pick parts from those various archives. To obtain a general overview, those information slices should be gather. Different approaches can be followed to achieve that integration, ranging from the merge of resources till the fusion of the extracted parts. In this paper, we introduce Metamorphosis – a Topic Maps oriented environment to generate conceptual navigators for heterogenous information systems – and we argue that Metamorphosis can be used to achieve the referred interoperability