- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Tue, 26 Feb 2002 16:25:03 +0000
- To: www-xml-xinclude-comments@w3.org
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, 26 February 2002 11:25:05 UTC