W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2000

Comments on Part 0: Primer

From: Curt Arnold <carnold@houston.rr.com>
Date: Tue, 2 May 2000 22:33:01 -0500
Message-ID: <002701bfb4b0$491c52e0$9344a018@houston.rr.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:52 UTC