[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XHTML m12n XSD

• From: Curt Arnold <Curt.Arnold@h...>
• To: xml-dev@l...
• Date: Fri, 05 Jan 2001 09:52:05 -0600

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
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JanMar/0040.
html).

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

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

and

<!--  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:complexType>
        <xsd:sequence>...</xsd:sequence>
        <xsd:attributeGroup ref="blockAttr"/>
    </xsd:complexType>
</xsd:element>

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.

• Follow-Ups:
  • Re: XHTML m12n XSD
    • From: Rick Jelliffe <ricko@a...>

• Prev by Date: Re: Traffic Analysis and Namespace Dereferencing
• Next by Date: open source tool
• Previous by thread: RE: XHTML m12n XSD
• Next by thread: Re: XHTML m12n XSD
• Index(es):
  • Date
  • Thread