Comments on XML Schema:Structure draft

First, congratulations to all involved in this draft. It is insightful and clear, and mostly very good. 

However I think the material relating to entities, export and namespaces is poor and should be rethought.

Here are specific comments.


1) In 3.6, surely it is a mistake to provide internal and external parsed entities as part of XSchema.  That would require a change to XML 1.0, which I think would be a very bad thing: XSchema should sit on top of XML 1.0 (both WF and DTD-valid XML 1.0) as a layer.  

The use of "strictly-speaking" and "nearly well-formed XML" in s 6.3 betray that XSchema is not compatible with XML 1.0.  Furthermore, it stops compatability with SGML, which is an infuriating path to take.

Does the XSchema group have any mandate to abandon XML 1.0 and SGML compatability? If so, why has the outside world not been informed of this? 


2) In 3.6.3 why baroque? And why use "system" instead of "href"?


3) 3.6.4 XML idea of notation is under-specified. It would be better to provide an attribute mime-media-type that can markup the MIME media type, and a list of (or extended XLink locating)  URIs for applications (programs, Java classes, etc) that can be downloaded, labelled to allow user or program selection according to preference.

It would be nice to indicate the relationship between NOTATION and data types: for example, it seems to me that when an element has a notation attribute, the system identifier of the notation declaration should be a URL pointing to the element which declares the data type in an XSchema datatype declaration.


4) The use of namespace URIs as schema identifiers contradicts the stated and hard-fought policy at the time of the namespaces draft.  It has been repeatedly insisted by Tim Bray and others that the Namespace URI gives a universal name and not a schema.  It seems underhanded.

In any case, if a schema used is a refinement of another, but there is no change to the declaration of a particular element, should the unrefined schema URI be used, not the refined schema URI?  For example, if I create my own version of HTML which refines the use of tables only, surely if I want general browsers to work I should name all the other elements against the unrefined HTML schema not the refined one. 

This kind of complication (should an XHTML browser download a big fat schema jsut to see if an element is in fact a refined HTML element?) rings lots of alarm bells with me. I think the overloading of namespace names as schema definitions should be withdrawn.  

The theoretical justficiation I would offer is that a name should not be tied to a use. Validity against a schema is a use; rendering at a client is a use; altering one use should not effect other uses; altering the schema should not require altering all stylesheets for documents. For example, if HTML 5 is released, I want to be able to continue to use HTML 4 stylesheets.  If the element names are tied to the schema, then I need to alter the stylesheet (in fact, what would happen is that people would use the html: qualifying prefix instead, or just the local part...circumventing the namespaces.)


5) The export restriction does not seem to correspond to a big need. Surely the same thing can be accomplished by exporting a less refined schema. 

If export does serve some purpose, it would be more powerful to export using names rather than just yes/no. In other words, a schema instance could allow the export of named subsets of declarations: this could be used to accomodate multiple versions of schemas within the same schema instance.


6) In s 2.5 clarify whether  elements and attributes are in different symbol spaces. RDF uses rdf:value for both element type names and attribute names.

Rick Jelliffe
Academia Sinica Computing Centre
Taipei, Taiwan