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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XHTML m12n XSD

Substitution groups (especially if the common ancestor and single membership
restrictions were removed per LC-96) could effectively replace parameter
entities for content models.

The use of parameter entities in a base DTD or a substitution group in a
schema is an invitation or hook for extension like declaring a function
virtual in C++.  Using redefine seems to be an automated way of patching
code to create an incompatible variant.  Sometimes you do have to do that,
but I prefer to use an open doorway instead of drilling through the wall.

One missing capability is the equivalent of substitution groups for
attributes.  In some sense, substitution groups gave you two ways to define
a named choice group, an explicit way where all the possibilities where
listed within the definition of the group and an implicit way where the
possibilities nominated themselves at their definition (see

If you wanted to do roughly the same for attributes, you could add:

<attributeGroup name="..." open="true | false : false"/>


<!--  top level attribute -->
<attribute name="...." groups="qname qname..."/>

If you wanted to declare that the block element could have additional
attributes defined in different models, but only those that explicitly
nominated themselves for that use:

<xsd:attributeGroup name="blockAttrs" open="true"/>
<xsd:element name="block">
        <xsd:attributeGroup ref="blockAttr"/>

Then in a second schema, you could say:

<xsd:attribute name="z-origin" type="xsd:double" groups="xhtml:blockAttrs"/>

Currently, you could only say that block contained any additional attribute
for a set of namespaces.

Could you tell me what the benefic of explicitly ignoring some content is
instead of analysizing the resulting schema set and doing some sort of
dead-code analysis.