- From: Curt Arnold <carnold@houston.rr.com>
- Date: Tue, 2 May 2000 22:33:01 -0500
- To: <www-xml-schema-comments@w3.org>
Section 2.3 Among these, the enumeration facet is one of the most useful and it can be constrain the values of almost simple type, except the boolean type. Why not the boolean type? xsi:null appears to use an enumerated boolean (allowing true but not 1). Anyway, I believe that xsl:null should accept false, 0, true and 1. With only true and 1 signifying null content. (you cannot create lists from complex types). For the narrative, I think it is probably more appropriate that you mention lists can't be derived from other list types. 3.4 Undeclared target namespaces I have a problem with this. If you are going to the point of defining a schema, these elements and attributes are in a conceptual namespace whether or not you give it a name. The way targetNamespace is defined, I cannot write one schema that could be used to validate a XML 1.0 sans namespace document and also used in a to validate a document with namespace support. I can't even use include since the targetNamespaces wouldn't match. What I would recommend is that targetNamespace be required for schema definition. However, the XML 1.0 binding mechanism could specify both a validation namespace and schema location. The noNamespaceSchemaLocation could be a list of two URI's with the first being the validation namespace and the second being the schema location. 4.2 Deriving Types by Extension Furthermore, the two content models are treated as two children of a sequential group. I actually prefer this behavior, but it might be out of synch with our recent discussion about behavior when the base type has content model mixed.
Received on Tuesday, 2 May 2000 23:43:38 UTC