OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Potential Issue With XSD Generation

In trying to finalize the XSD generation I've run into a potentially
unsolvable issue (at least within the scope of what we can do for 1.3).

In XSD you cannot simply redefine a content model the way you can in DTD
and RELAX NG: the redefined content model has to be "consistent" with the
base and this leads to the need for various workarounds in the XSD. In
particular, if the base element's content model is a sequence you cannot
simply modify the sequence in a redefine: every "particle" in the base
content model has to be accounted for in the redefined content model, so,
for example, you can't simply leave things out.

In the specific case of the technical content strict task body constraint,
the constraint as defined for RNG and DTD cannot translate directly to
XSD. This is reflected in the 1.2 XSDs where Eric had to add another level
of named groups so that those groups could be individually redefined in a

But those groups have no purpose other than to satisfy this aspect of
XSD--they are not needed for RNG or DTD.

For the purpose of generating XSDs from the RNGs I can't see any way to
synthesize the equivalent named groups and then generate redefinition of
those groups from the RNG version of the strict task body constraint.

The only option I can see is to hard code the generation of these XSD
modules for the purpose of automating the generation of the OASIS-provided
XSDs and document that for other constraints it may be necessary to
hand-create the working XSD declarations.

There may potentially be a deeper problem with the XSDs in that any base
content model that is a sequence rather than a repeating OR group may be
unconstrainable without first interposing another level of named groups,
as Eric did with task. For example, <prolog> is a sequence declared in the
1.2 XSDs as a simple sequence content model. I tried creating a constraint
module that adds a new required specialization of <data> and the XSD
parser flagged it as being an invalid restriction. It is, in part, this
aspect of XSD that makes their use for DITA problematic, at least with XSD
1.0 (the XSD 1.1 override mechanism might help, but it's not universally
implemented yet as far as I know).

Unless someone can offer a better solution I am going to take the shortest
path to completion and simply hard-code the generation of these 1.3
constraint modules.



Eliot Kimber, Owner
Contrext, LLC

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]