- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Tue, 29 Feb 2000 08:04:44 -0700
- To: "'www-xml-schema-comments@w3.org'" <www-xml-schema-comments@w3.org>, "'xml-dev@xml.org'" <xml-dev@xml.org>
Here are some comments on XML Schema structures based a quick initial read: Section 2.2: Model groups is classified twice in the definition of schema component, once as a secondary component and once as a help component. Section 2.2.1.3: I can't get my mind around the "Each is (sic) complex type definition is..." part. Aren't some complex type definitions a extension of the ur-type? Section 2.2.2.2: Should equiv class names be QName's? Section 4.1: It seems unnecessary and complicating to allow multiple annotation elements within the schema element. It would tend to be interpreted as pertaining to the next child element vs being a annotation of the schema as a whole. It would also seem that allowing an RDF element for metadata would be appropriate. Something like (rdf:rdf?,annotation?,(include|import)*,(simpleType|complexType| element|group|notation)+) Section 4.3.1: In the long run... Actually, the schema components do appear to have id attributes of type ID which allow referencing schema components now. Section 4.4.3: minBound and maxBound appear in addition to minExclusive et al in the content of complex type. anyAttribute does not allow annotation. I think it would be useful to include descriptions of what alien attributes might be anticipated. Section 4.4.1: I assume the fairly complicated section on attribute groups from other namespaces is to support validation of attributes like xlink:href by defining a attribute group in the xlink schema and namespace and including an attribute group reference in the element's definition? Maybe an example would be useful. would be useful. Doesn't appear to give you any mechanism to restrict the values, but Section 4.4.7: processContents I assume that one of these modes is appropriate for XSLT literal result elements (ideally that the element content model is not validated, attribute presence is validated, attribute typing is validated if there is not a "{ }" in the attribute). any does not allow annotations either. Again it would be useful to include descriptions of what alien elements might be anticipated. I assume that you could support different processContent setting for different namespaces by using <any> elements in a <sequence> such as: <sequence minOccur="0" maxOccur="*"> <!-- not the write namespace but you get the idea --> <any minOccur="0" namespace="http://www.w3.org/XSLT" processContents="strict"/> <any minOccur="0" namespace="##any" processContents="lax"/> </sequence> If not, how do you do it. Section 5.3.2: "schemaLocation" attributes can occur on any element participating... validation root. Unless I'm reading this wrong (in which case better prose is in order), this appears to make event-based validation difficult if not impossible since you may not know the schema location until much of the document has been processed. If would seem reasonable that "schemaLocation" indicates the schema to be used for the scope of the containing element. That would also allow for different schemas for the same namespace (for example, a document that contains fragments from files that were written with different versions (and hence different schemas) of one application (same namespace) Appendix A: Schema for Schemas annotation, documentation and appinfo do not appear in structures schema (they are in the datatypes schema), though they are in the structures text. The <sic> element appears though not discussed in the body of the document. Note: Derivation by restriction of complex types is not discussed in detail in the document though there is substantial potential for ambiguity. I'll try to outline something in a separate message.
Received on Tuesday, 29 February 2000 10:07:24 UTC