xml-dev - RE: Schema for XSLT (concerns mixed content, content attribute)

["Arnold, Curt" <Curt.Arnold@hyprotech.com>]

Don Box wrote:

I just spent the afternoon massaging my schema for XSLT. If you want to
check it out, it is at:

        http://www.develop.com/dbox/xml/xslt.xsd

I'd love to get feedback, especially from those who have April 7-compliant
schema parsers/validators. I still need to go through and tighten up the
references to simple types, add xsd:unique, and catch any bugs I am too
tired to see today.


Curt Arnold reply:

First, a few comments on Don's schema for XSLT then a discussion about some problems representing XSLT's content model with schema.

The derivedBy attribute was not specified on the definition of the copy and message complex types as appears to be required by Schema representation constraint 1.1

The param element reference in the named-template type definition should have a minOccur="0" and a maxOccur="unbounded".  As written, a template has to have one and only one param.

You frequently use type-scoped element definitions.  I try to avoid these unless a specific tag-name has a distinct content models in different contexts since it will be difficult if not impossible to
generate an equivalent DTD.

Second, Schema doesn't seem to have the ability to adequately represent the content model of <xsl:template> or <xsl:for-each>.  <xsl:template> content should be zero or more <xsl:param> elements
followed by template content.  <xsl:for-each> content should be zero or more <xsl:sort> elements followed by template content.

Your schema represented these as:

    <complexType name='template' content='mixed'>
        <element ref='xsl:instruction' />
        <any namespace='##other' />
    </complexType>

    <complexType name='named-template' base='xsl:template-with-space' derivedBy='extension' >
        <element name='param' type='xsl:variable-definition'/>  <!--  should have a minOccurs/maxOccurs here -->
        <attribute name='match' type='xsl:pattern' />
        <attribute name='name' type='QName' />
        <attribute name='priority' type='xsl:XPathNumber' />
        <attribute name='mode' type='QName' />
    </complexType>

    <complexType name='template-with-space' base='xsl:template' derivedBy='extension' >
        <attribute ref='xml:space' />
    </complexType>

    <complexType name='for-each' base='xsl:template-with-space' derivedBy='extension' >
        <element name='sort' type='xsl:sort' minOccurs='0' maxOccurs='unbounded' />
        <attribute name='select' type='xsl:expr' use='required' />
    </complexType>

My interpretation of derivedBy='extension' is that any content defined in the derived type appears after the content in the base type.  (I looked but couldn't see any definition of special behavior if
the base complexType was mixed)  So that your definitions would allow template content then <xsl:sort> or <xsl:param> elements.  However, since the only mechanism to get mixed content is through a
content='mixed' attribute on a <complexType> element and that the only mechanism to build a content model off of a complexType is restriction or extension, there does not seem to be a mechanism for
doing what you would really want.

The best approximation you could do with the working draft is to not use derivation and create a mixed model that allows <xsl:sort> or <xsl:param> to appear anywhere in the mixed content.

If you however, had a <mixed> grouping element then you could adequately the content model like:

<complexType name="for-each">
	<element name="sort" type="xsl:sort" minOccurs='0' maxOccurs='unbounded'/>
	<mixed>
        		<element ref='xsl:instruction' />
        		<any namespace='##other' />
	</mixed>
</complexType>

That lead me to look at the content attribute of complexType which appears to only provide information in a very few places and has substantial potential to be inconsistent with other parts of the
type declaration.  Elimination of the content attribute would seem to eliminate some complexity.

The content attribute can have values of elementOnly, textOnly, mixed and empty.

textOnly can usually be implied by the type attribute referencing a simple type or a <simpleType> child element.  The equivalent of content='textOnly' would be nothing more would be type='string'.
There doesn't seem to be a case where content='textOnly' adds value.

elementOnly can be implied by a type attribute referencing a complexType or a <complexType> child element.

If we had the <mixed> group tag, then mixed content is just a particular flavor of complex type.

That leaves empty.  Either an <empty/> element like in previous drafts or better yet defining an "empty" complex type in the schema for schema that is the default base type if no type is defined and
would be the default base type for complexType elements.

<!--  these would all be equivalent (unless someone defined a locally name empty complex type)  -->
<element name="apply-imports" type="empty"/>
<element xmlns:xsd="http://www.w3.org/1999/XMLSchema" name="apply-imports" type="xsd:empty"/>
<element name="apply-imports"/>


I've posted an HTMLHelp file (http://home.houston.rr.com/curta/xslt.chm) based on a simplified version of Don's schema for XSLT (http://home.houston.rr.com/curta/xslt.xsd) on my home page.

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************