This includes :

Note that for this feature, the exposition of the XSD methods should be enough.

This break down structure enables future conversions into other formats such as Relax NG to be easily integrated. Indeed, only the step 3 and other would have to be changed in order to generate the appropriate format.

Schemas elements are mapped to DTD ELEMENT having the same name with explicit content(s) or PE(s) and DTD ATTLIST with explicit attribute(s) or PE(s).

Local elements are made global (brought to the root level) and inserted just after the object they originated from. But conflicts may arise because of this globalization of local elements. XS2DTD V1 does not resolve the conflicts but it is planned to be achieved in the next releases. So for the moment, local elements are globalized and a warning is raised whenever a conflict is detected.

Empty schemas elements are converted into EMPTY DTD elements.

The following schemas objects are not treated: nillable, form, fixed, default, unique, key and keyref .

As for simple types, global complex types are represented with 2 global PEs, one for the Content Model and one for the Attributes (if any). Groups are managed like complex types content model.

The possible conversions of a complex type content model are:

Global attributes are mapped as global PEs.

Local attributes are converted into ATTLIST DTD element.

Annotations within objects are stored as is, in the DTD handler, within the comment element. Global annotations are inserted at the exact same location in the DTD handler.

The DTD dumper is responsible to format this information. For the first initial release, the output will diferenciate : appinfo/ toclevelsx, appinfo/ para and documentation that will be treated as appinfo/para. All other annotation contents will not be managed.

Example:

The redefine mechanism enables to redefine simple and complex types, groups, and attribute groups that are obtained from external schema files. Like the include mechanism, redefine requires the external components to be in the same target namespace as the redefining schema.

The redefine element acts very much like the include element as it includes all the declarations and definitions from the included schema. However, the main difference is that the base type of redefined elements is equivalent to the original element.

A redefinition is actually an include element which content is redefined inside the including element (the one that is redefining a declared element).

In terms of conversion, and since the ‘redefinable’ elements are all mapped though PEs, the redefinition is actually applied on their PE’s content. Practically speaking, redefining an object consists in creating new PEs, called redefining PEs, which are overcharging other existing PEs. Those redefining PEs will happen to have the same name than the overcharged ones and must be declared before the inclusion call (the include ).

In the DTDHandler, an attribute redef will give the ID of the redefined element and show its redefinition.

*) Idée de mise en oeuvre

---------------------

Dans le cas de restriction, à mon avis pas grand chose à dire, il faut utiliser le mecanisme standard.

Dans le cas de l'extension, peut etre -pour faciliter les choses- est il possible d'agir en deux temps :

1) utiliser le mecanisme d'extension classique :

    ecrire dans le dtdHandler une peDef qui va dans son contentModel va inclure un peRef sur lui meme.

    Garder quelque part la trace qu'il s'agit d'un redefine concernant tel schema.

2) faire au final une passe sur le dtdHandler cherchant ces cas de figure :

    - pour un peRef inclus dans le peDef en question

        aller chercher dans le handler correspondant aux schema redefini la peDef

        remplacer le peRef par le content model de la peDef trouvé.

Il me semble que celà serait assez simple, mais je laisse mike faire ses choix à ce propos

car c'est lui qui maitrise le mieux les algos sur tout celà.

Include and imports are mapped into external PEs such as:

<xs:include schemaLocation="foo.xsd"/>

Would give in DTD:

<!ENTITY % foo PUBLIC "foo.ent">

%foo;

Actually, it is impossible to use xs2dtd only for the purpose of retrieving id’s for schema Output. Processes 2 and 3 are wrapped-up.

People making the integration will remove this limitation by doing the following :

Separate the wrapping process (tree walker) from the creation of the DTDHandler ; In DTDProcessor , create a new method wrappSchema(SDSchema) , based on verticalBuild method, which would only parse the XSD loaded schema and wrapp the objects on the fly. Modify verticalBuild so that it takes the output of the method wrappSchema as argument.