next up previous
Next: 3. Management Up: 2. Programme and Methodology Previous: 2.1 Overall goals

2.2 Deliverables and Work Packages

Work Package 1: Identification and Description of Test Cases We will need a number of independently designed document types, application data models, and pairs of the two to use in the other work of the project. Examples will be sought from existing document-oriented DTDs, such as the XHTML DTD (see, from existing data-oriented DTDs, such as the e-commerce transaction DTDs of the Open Applications Group (see in addition to the schema, DTD and data model for XML Schema itself, which we have already worked with in the unmarshalling direction. Starting from the application data end, possible examples include the patient record model of the European Committee for Standardization CEN TC251 (see in UML, the Dublin Core bibliographic metadata model (see in RDF, and a teachers-courses-students database developed jointly between the Language Technology Group and Microsoft in the Entity-Relation model. The deliverables will include not only an inventory of designs, but at least some example documents in each case, as well as schemas or partial schemas, which will have to be created in many cases.

Work Package 2: Schema Annotation XML Schema provides for arbitrary annotations to be added to the declarations and definitions (called schema components) which together define a document type, that is, a set of documents with a common structure and common purpose. The deliverable from this work package is a design for a set of annotations which specify the correspondence between schema components and application data model components. This breaks down into two tasks:
a) design the syntax of the annotation mechanism, that is, whether to use elements or attributes, which aspect of schema extensibility to exploit, etc.;
b) determine what vocabularies are needed to identify the different kinds of application model components, e.g. entity, relation, attribute etc. for Entity-Relation, or class instance, instance variable, list for an object-oriented programming language.

Work Package 3: Language-specific Unmarshalling: Direct prototype

This Work Package is the proof of concept for the architecture we have in mind, developing a prototype for the simplest part of the overall design, and testing it on real examples.

Task 3.1: Design and Construction
The deliverable of this Work Package is an implementation of a compiler from XML Schemas containing language-specific annotations as designed in Work Package 2 above into an XSLT stylesheet for unmarshalling, using the XSLT element extension mechanism. Three tasks here:
a) design one set of language-specific extension elements;
b) Implement the schema 1#1 stylesheet compiler, specialised to one language-specific vocabulary and targeting those extension elements;
c) implement the extension classes in the context of an XSLT implementation. The choice of implementation will determine the choice of language: C if we use our own streaming XSLT processor, Java if we use XT, James Clark's public domain XSLT processor.

Task 3.2: Deployment and Testing
This implementation gives us the basis for actually annotating schemas and unmarshalling from real document instances to test the viability of our approach, and explore its appropriateness to the three broad use-cases as outlined above in Work Package 1. The deliverables will be annotated versions of schemas for a number of the test cases delivered by Work Package 1 above, along with improved versions of the deliverables from Task 3.1.

Work Package 4: From Low- to High-level Annotation

To achieve our goal of appropriate modularisation, we need to elaborate the first deliverable from Work Package 3 above (the schema-annotation to stylesheet compiler) so that instead of implementation-language-dependent annotation vocabularies which can be compiled directly to application-structure-building stylesheets, we can annotate a schema in a domain-appropriate high-level modelling language such as Entity-Relation, EXPRESS or UML, and then parameterise the compilation process by a further specification of the correspondence between terms in that high-level model and implementation terms in a particular operating environment. The deliverables are thus parallel to those of Tasks 3.1 and 3.2 above, but based on high-level annotation and parameterised compilation.

Work Package 5: Marshalling

All the above has focussed on unmarshalling from XML documents into application structures. This Work Package turns to the question of marshalling application structures into XML documents. There are two different approaches to be explored here. The first is based on compiling the annotations of Work Package 3 into e.g. methods for the classes involved to achieve marshalling functionality. We are not aware of any language-independent precedent for this, in cases where the document structure was designed prior to or independently from the application data model.

Ambiguity and overloading are the obvious stumbling blocks. The alternative, although more speculative, also offers more if it is successful. There is some literature in areas of formal language theory applied to layout (e.g. Feng 1993) and applied to translation (e.g. Yellin 1988) which explores the annotation of one of a pair of grammars, either context-free or finite-state, with information about its relation to the other. The work may offer help in at least identifying properties of document schemas (which are isomorphic to context-free grammars) and application data models (which are relatable to grammars in most cases) which would be necessary to allow the automatic creation of marshalling understood as a similar sort of transformation as in the unmarshalling case.

Work Package 6: Second-order compilation

When an application data model exists, but no document definition work has been done to support XML receipt or delivery, automatic generation of an XML schema complete with annotation would fit well into the overall picture.

Task 6.1 Design Exploration
In principle it would be best to start at the modelling language level, then map from UML or EXPRESS or RDF schema to
1) an XML Schema;
2) the necessary schema annotations.
The major stumbling block that we envisage is when there are re-entrancies or circularities in the application model: when to choose foreign keys/ ID- IDREF/linking vs. embedding. The work on dataguides introduced above offers a promising place to start, going from data 1#1 semi-structured data 1#1 data guide 1#1 schema. How to generate the appropriate mapping annotations as part of this process is an open question.

Task 6.2: Implement and Evaluate
For evaluation, we can take the second-order compiler, apply it to a model for which we actually do have an existing schema, e.g. XML Schema itself, and compare results.

next up previous
Next: 3. Management Up: 2. Programme and Methodology Previous: 2.1 Overall goals
Henry Thompson