RE: XML Schema for XInclude

The schema is not meant to be normative for the xinclude namespace, but
your suggestions are attractive.  I will take them to the working group
for discussion.

As far as whitespace normalization using xs:token, I don't think that's
a good idea.  The XInclude processor looks for the strings "text" and
"xml", and any whitespace will cause it to fail.  If xs:token encouraged
someone to put whitespace in there, inclusion would only work when the
schema was applied and performed normalization.  I think it is a better
description of the inputs of the XInclude processor to not allow any
whitespace.

- Jonathan

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com]
> Sent: Tuesday, February 26, 2002 8:25 AM
> To: www-xml-xinclude-comments@w3.org
> Subject: XML Schema for XInclude
> 
> Hi,
> 
> Congratulations on the XInclude Candidate Recommendation. The addition
> of xi:fallback is a great touch.
> 
> I realise that it's non-normative, but as it's currently written, the
> XML Schema for XInclude is particularly resistant to change - for
> example, it wouldn't be possible for someone to adapt the schema such
> that they only allow XInclude elements with an explicit parse
> attribute, or where the xi:include element had to contain certain
> elements in another namespace.
> 
> I think that people might want to make these kinds of changes when
> incorporating XInclude into their own documents. I'd suggest,
> therefore, that the XML Schema be changed to the following:
> 
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>            xmlns:xi="http://www.w3.org/2001/XInclude"
>            targetNamespace="http://www.w3.org/2001/XInclude"
>            finalDefault="extension">
> 
> <xs:element name="include" type="xi:includeType" />
> 
> <xs:complexType name="includeType" mixed="true">
>   <xs:choice minOccurs='0' maxOccurs='unbounded' >
>     <xs:element ref='xi:fallback' />
>     <xs:any namespace='##other' processContents='lax' />
>     <xs:any namespace='##local' processContents='lax' />
>   </xs:choice>
>   <xs:attribute name="href" type="xs:anyURI" use="required"/>
>   <xs:attribute name="parse" use="optional" default="xml"
>                 type="xi:parseType" />
>   <xs:attribute name="encoding" type="xs:string" use="optional"/>
>   <xs:anyAttribute namespace="##other" processContents="lax"/>
> </xs:complexType>
> 
> <xs:simpleType name="parseType">
>   <xs:restriction base="xs:token">
>     <xs:enumeration value="xml"/>
>     <xs:enumeration value="text"/>
>   </xs:restriction>
> </xs:simpleType>
> 
> <xs:element name="fallback" type="xi:fallbackType" />
> 
> <xs:complexType name="fallbackType" mixed="true">
>   <xs:choice minOccurs="0" maxOccurs="unbounded">
>     <xs:element ref="xi:include"/>
>     <xs:any namespace="##other" processContents="lax"/>
>     <xs:any namespace="##local" processContents="lax"/>
>   </xs:choice>
>   <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> 
> </xs:schema>
> 
> This way I could write a schema that would define the xi:include
> elements that I could process with an XSLT stylesheet, for example:
> 
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>            xmlns:xi="http://www.w3.org/2001/XInclude"
>            targetNamespace="http://www.w3.org/2001/XInclude"
>            finalDefault="extension">
> 
> <xs:simpleType name="anyURINoFragment">
>   <xs:restriction base="xs:anyURI">
>     <xs:pattern value="[^#]+" />
>   </xs:restriction>
> </xs:simpleType>
> 
> <xs:redefine schemaLocation="xinclude.xsd">
> 
> <xs:complexType name="includeType">
>   <xs:complexContent mixed="true">
>     <xs:restriction base="xi:includeType">
>       <xs:choice minOccurs='0' maxOccurs='unbounded' >
>         <xs:element ref='xi:fallback' />
>         <xs:any namespace='##other' processContents='lax' />
>         <xs:any namespace='##local' processContents='lax' />
>       </xs:choice>
>       <xs:attribute name="href" type="xs:anyURINoFragment"
>                     use="required"/>
>       <xs:attribute name="parse" use="optional" fixed="xml"
>                     type="xi:parseType" />
>       <xs:attribute name="encoding" use="prohibited"/>
>       <xs:anyAttribute namespace="##other" processContents="lax"/>
>     </xs:restriction>
>   </xs:complexContent>
> </xs:complexType>
> 
> </xs:redefine>
> 
> </xs:schema>
> 
> ---
> 
> By the way, I made a few other changes when rewriting the XInclude
> schema above:
> 
> I made the type for the parse attribute be derived from xs:token
> rather than xs:string. The only difference is in the way whitespace is
> normalized prior to validation. Using xs:token makes the schema concur
> with the definition in the (non-normative, again) DTD, which allows:
> 
>   <xi:include parse="   text   " href="foo.txt" />
> 
> As it was, based on xs:string, the above would not be allowed because
> '   text   ' is not either 'text' or 'xml'. I don't know which way you
> want to play it, but thought that you probably wanted whitespace to be
> normalized automatically.
> 
> I changed the xs:any wildcard in the type for the xi:fallback element
> so that it allows other namespaces (##other) rather than allowing only
> those in the namespace '#other' (what a difference a # can make!). I
> also added an xs:any wildcard to allow elements in no namespace
> (##local), as you had this for xi:include and I thought you probably
> wanted them to be the same for both elements.
> 
> I added a namespace="##other" attribute on to the xs:anyAttribute
> wildcard for the xi:fallback element rather than ##any (the default),
> and made it process those attributes with lax validation rather than
> strict (the default). Again, this ties in with what you have for
> xi:include and makes more sense - you want to allow any attribute as
> long as it is not in no namespace nor in the XInclude namespace, and
> those that are present should be validated only if a definition is
> available.
> 
> Because I'd separated out the complex types, I added a finalDefault
> attribute to the xs:schema element with a value of 'extension' to
> disallow people from adding to the content models that are defined in
> the schema. What you have should allow people to create restricted
> versions of xi:include and xi:fallback that include their own elements
> and attributes; they shouldn't need to extend the models. Only
> allowing derivation by restriction ensures that an application that
> can process xi:include and xi:fallback elements correctly will also be
> able to process any derived versions that people come up with
> correctly.
> 
> Cheers,
> 
> Jeni
> ---
> Jeni Tennison
> http://www.jenitennison.com/

Received on Tuesday, 12 March 2002 18:17:57 UTC