xml-dev - W3C XML Schemas Review comments (Was Re: Community help on W3C XMLSchema

["Thomas B. Passin" <tpassin@home.com>]

Attached is the second set of review comments I have
generated against the W3C XML Schemas CR.   I'll continue to
do more review as I get time.

Regards,

Tom Passin
Review of Parts of XML Schema Part 1
Thomas B. Passin (tpassin@home.com)
5 November 2000

In the Abstract:
"The schema language, which is itself represented in XML 1.0 and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML 1.0 document type definitions (sic) (DTDs). "

========== comment =============================
What does "substantially reconstructs" mean?  Does it mean that some capabilties found in DTDs cannot be expressed by XML schemas?  if so, somewhere there should be a (non-normative) summary of what cannot be expressed.  It would be better to say

"The schema language considerably extends the capabilities found in XML 1.0 document type declarations, with a few exceptions (section xxx). The schema language itself has an XML 1.0 serialization syntax."

The correct term for a DTD is "declaration", not "definition".
==================================================


"2.2.2.2 Element Substitution Group
In XML 1.0, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model."

========== comment =============================
Suggest clarifying this sentence by referring to the XML 1.0 Recommendation (with a hyperlink) to avoid possible confusion - after all, the XML-schema recommendations are going to be applied to document starting with <?xml version='1.0'?>, whereas this sentence suggests that it will not apply to xml version 1.0.

Also suggest saying "... the corresponding DTD content model." to avoid confusion as to whether a DTD or Schema content model is meant.

==================================================

"[Definition:] Through the new mechanism of element substitution groups, XML Schemas provides a more powerful model supporting substitution of one named element for another. Any global element declaration can serve as the defining element, or head, for an element substitution group. Other global element declarations, regardless of target namespace, can be designated as members of the substitution group headed by this element. In a suitably enabled content model, a reference to the head validates not just the head itself, but elements corresponding to any member of the substitution group as well."

========== comment =============================
Request a revision of this section for more clarity.

1) Replace "supporting" by "allows".  This is more direct - what is "supports" supposed to indicate that differs from "allows"?

2) It is unclear whether the head of an element substitution group has some privileged status.  If it does, what is it?  Perhaps it is that the head must appear in places in the schema, whereas any of the other members of the substitution group may appear in the corresponding places in an actual document.  If so, say so clearly.  

3) In the last sentence, either explain "suitably enabled content model", or delete it since it suggests that something else is required beyond defining the substitution group.

4) The last sentence is confusing because validation applies to an instance documment, but the usage in the sentence suggests that it (the sentence) applies to the schema rather than to an instance.

5) If any non-head member of a substitution group is used somewhere in the schema, can that indicate that any member of the group can be substituted there, or is the head the only type that can be used for this purpose?

==================================================

"2.2.2.3 Attribute Declaration
An attribute declaration is an association between a name and a simple type definition, together with occurrence information and (optionally) a default value. The association is either global, or local to its containing complex type definition. Attribute declarations contribute to validation as part of complex type definition validation, when their occurrence, defaults and type components are checked against an attribute information item with a matching name and namespace."

========== comment =============================
This does not say specifically whether attributes can be defined separate and apart from any element. Taken literally, the section seems to say that they can be.  Recommend saying this explicitly whichever way is intended, since they must be so associated in the XML 1.0 Rec (sec 3.3).
==================================================

"2.2.2.4 Notation Declaration
A notation declaration is an association between a name and an identifier for a notation. For an attribute information item to be valid with respect to a NOTATION simple type definition, its value must have been declared with a notation declaration."

========== comment =============================
Does this really apply to "validation", or does it mean that the type specified for an attribute in the ***schema*** has to have been declared by a notation declaration (where applicable, of course)?  

I believe the intent is to show how to declare a new type (that of the specific notation) that can then be used to specify the type of the attribute's value.  If this is correct, please rewrite this section to say so clearly and directly.

Otherwise, the section need revision for clarification.
==================================================

"2.2.3.1 Model Group
A model group is a constraint in the form of a grammar fragment that applies to lists of element information items. It consists of a list of particles, i.e. element declarations, wildcards and model groups."

========== comment =============================
This use of the term "particles" conflicts with the first use of the term, at section 2.2, where a particle is listed as something ***separate*** from a model group:

"Finally, the "helper" components provide small parts of other components; they are not independent of their context and <NB>cannot be independently accessed</NB>:
- Annotations 
- Model groups 
- Particles 
- Wildcards "

The use of the term "particle" should be made consistent everywhere, or it should be explained where it is used in different ways.
==================================================

In section 2.2.3.1:
"Disjunction (the element information items match one of the particles)"

========== comment =============================
Does this mean "exactly one" or "one or more"?  Say which one explicitly.
==================================================

"2.2.3.2 Particle
A particle is a term in the grammar for element content, consisting of either an element declaration, a wildcard or a model group, together with occurrence constraints. Particles contribute to validation as part of complex type definition validation, when they allow anywhere from zero to many element information items or sequences thereof, depending on their contents and occurrence constraints."

========== comment =============================
Refer to comment above on use of the term "particle".  
==================================================

"3.8 Particle Details
As described in Model Group Details (§3.7), particles contribute to the definition of content models. The particle schema component has the following properties:"

========== comment =============================
Now a "particle" "contributes" to the definition of a content model.  Please make sure the term is used and defined consistently.  (This will be my last comment about this issue!)
==================================================

In Section 2.2:
"NOTE: We have not so far seen any need to reconstruct the XML 1.0 notion of root. "

========== comment =============================
Does this mean that we are discarding "root", or that we are keeping it as is?  Please clarify this sentence.
==================================================

In section 2.2 :
"During validation, [Definition:] declaration components are associated by (qualified) name to information items being validated.

On the other hand, [Definition:] definition components define internal schema components that can be used in other schema components"

========== comment =============================
This seems to say that a simple or complex type definition is not associated with any information item during validation.  Is this correct?  If not, please clarify.
==================================================

In section 2.2:
"[Definition:] A type definition whose declarations or facets are in a one-to-one relation with those of another specified type definition, with each in turn restricting the possibilities of the one it corresponds to, is said to be a restriction. The specific restrictions might include narrowed ranges or reduced alternatives. "

========== comment =============================
Does this include the complete elimination of a declaration or facet?  Please be specific about this.
==================================================

"2.2.1.1 Type Definition Hierarchy
[Definition:] Except for a distinguished ur-type definition, every type definition is, by construction, either a restriction or an extension of some other type definition. The graph of these relationships forms a tree known as the Type Definition Hierarchy. "

========== comment =============================
It is unclear that these graphs should be considered to form a tree.  For example, say that type B is derived from type A by extension, while type C is derived from type A by restriction.   Now, I think that most people would consider that C is a child of A in a hierarchy.  But isn't it true that element A could be derived from element B by restriction?  If so, then which should be regarded as the parent in a hierarchy?  And if this is not well defined, then we don't really have a hierarchy or tree.  

I bring this up because, after reviewing the occurances of "Type Definition Hierarchy" in Part 1, I don't see any place where the supposed fact of this graph being a tree is actually used for anything.  So far as I can see, it is only used to have a term for referring to the collection of related types. 

If this is correct, I suggest not defining a new term that carries unnecesary implications.  Leave it at "Type Definition Graph", or something like that.
==================================================

In section 2.2.1
"Type definitions form a hierarchy with a single root."

========== comment =============================
Can't there be multiple hierarchies of types within a single schema?  For example, I don't see <xhtml:a>, <xhtml:table>, and <xhtml:img> types being in the same hierarchy even though they may all derive from "anyType".  This relates to the comment above.
==================================================

"2.2.4 Identity-constraint Definition Components
An identity-constraint definition is an association between a name and one of several varieties of identity-constraint related to uniqueness and reference"

========== comment =============================
This sentence implies that there are varieties of identity-constraint that are not related to uniqueness and reference.  However, in section 3.10 it appears that there are no other varieties. If this is correct, suggest rewording like this:

"An identity-constraint definition is an association between a name and an identity-constraint.  Identitiy- constraints relate to uniqueness and reference ( see section 3.10)."
==================================================

"2.2.5 Group Definition Components
There are two kinds of convenience definitions provided to enable the re-use of pieces of complex type definitions: model group definitions and attribute group definitions."

========== comment =============================
This heading is incorrect.  The section does not discuss components of group definitions.  Rather, it discusses definitions of attribute group and element group components.  Probably this is meant:

"Component Group Definitions"
==================================================