Comments on Working Draft "Basic XML Schema Patterns for Databinding Version 1.0", October 31, 2007

We are pleased to provide you with the XML Schema Workgroup's review of 
your draft: "Basic XML Schema Patterns for Databinding Version 1.0", dated 

 October 31, 2007 [1].  First of all, please accept our sincere apologies 
for the long delay in providing this review.  We hope these comments are 
still useful to you.  We also note that there was some sentiment in the 
schema working group that with a bit more work, we might have made the 
following comments a bit shorter.  I hope you will bear with our decision 
to send them now, rather than to work on them further.

The XML Schema Workging group very much appreciates that the work being 
done by your working group will greatly enhance the value of XML Schemas, 
and  we are grateful for your work on this draft.  In the following, we 
comment  primarily about the ways in which the Schema Patterns draft 
refers to the  XML Schemas (XSD) Recommendations, and the ways in which it 

uses the  features of XSD.

Most significant concerns
-------------------------

* References to concepts and terminology from XSD need to be made more 
precise.  For example, section 1.3 says "A document claiming conformance 
to this specification ... MUST conform to the [XML Schema 1.0 
Recommendation]", but XSD provides no conformance requirements for 
"documents" in general.  It would be more appropriate to say that "A 
document claiming conformance to this specification ... MUST be a 'schema 
document' [2], as defined in [XML Schema 1.0 Recommendation], and MUST 
therefore meet the "Constraints on the representation of schema components 

 in XML" [3] provided therein."   Actually, there's a further mismatch on 
infosets vs. serialization; see next point.

* 1.3 also says that a document conforming to the databinding 
specification must be a well formed XML 1.0 document;  XSD defines a 
schema document as an Infoset with <xs:schema> as the root element.  You 
should make clear whether the mismatch is intentional, and if so rewrite 
the text suggested above accordingly.  Otherwise, you should change to 
indicate that a conforming document is infact an Infoset, consistent with 
XSD.  That will mean changing the many references to XML 1.0 documents 
that appear throughout your draft.

* Section 1.4 suggests that a conforming application "SHOULD be able to 
process any valid [XML Schema 1.0] document.".  First of all, there's some 

question as to whether a SHOULD is appropriate in a conformance  section. 
Notwithstanding that, the reference to [XML Schema 1.0]  documents is 
again not strictly clear, since XSD talks about instances to  be validated 

as well as schema documents.  We suggest a formal reference to  'schema 
documents' [2] as in the first point above.

* Section 1.4 says that conformance requires that an implementation:  " 
MUST produce a data model exposing all of the [XML 1.0] element node and 
attribute node content described by the originating [XML Schema 1.0] 
document.", but "described by" is not a formal relation or operation 
provided for in XSD.  Especially in a conformance requirement, this seems 
too informal.

* Schema documents vs. schemas: Following up on the point above, there are 

 schema documents that do not stand on their own in defining a schema 
that's useful for validation.  For example, if a schema document merely 
defines a complext Type T as being derived by extension from type B with 
attribute A, then you don't really know what the type is until you find 
the base type B, and that may well be in a different schema document. 
Maybe there is element content in effective type T.  If there is an 
element E declared of type T, then what does the requirement to "[expose] 
all of the [XML 1.0] element node and attribute node content described by 
the originating [XML Schema 1.0] document" mean?  The problem is that it's 

not really schema documents that directly call for or don't call for 
content in documents to be validated.  Schema documents contribute to the 
construction of a schema (formally defined at [4]), which in turn contains 

 element declarations, etc. that can be used to require or allow content 
in  documents to be validated.  >>It seems that some serious thought is 
needed  as to whether it's schema documents or schemas that would conform 
to the  databinding specification.<<  In any case, referring to the 
element or  attribute content "described by a schema document" is not just 

too  informal; as suggested above, it's likely that you really want to 
talk  about the element or attribute content allowed by a schema. 
Conversely, you could more clearly define a set of rules relating to 
individual schema documents if that's what you really intend.

* Section 1.4 says that conformance requires that an implementation: "MUST 

be able to consume any well-formed [XML 1.0] document which satisfies 
local-schema validity against the originating [XML Schema 1.0] document 
exposing all of the [XML 1.0] element node and attribute node content in 
the data model."  Again, local-schema validity is not a relation defined 
on the pair {instance, schema document}, it is (presuming you indicate 
which type or element declaration to start with) defined on the pair 
{instance, schema}" 

* Section 2:  "The [XPath 2.0] expression is located from an [XML Schema 
1.0] element node which may be the document element, or an element 
contained inside an [XML 1.0] document such as [WSDL 2.0] description." 
It's not quite clear what is meant in saying that an "[XPath  2.0] 
expression is located from".  Is this trying to establish the "Context 
Node" for the XPath expression as being the node of the <xsd:schema> 
element? If so, we recommend you say that more clearly, preferably with 
hyperlinks to the pertinent parts of the XPath Recommendation.  Also, the 
phrase "may not" can be read as prohibiting the case where the element 
note is the document node.  I suspect you meant "need not".  Finally, [XML 

 Schema 1.0] element node isn't a term that appears in the XSD 
Recommendation;  did you mean the "root element information item of the 
schema document"?

* Sections 2.x:  The phrase "An [XML 1.0] document exibits the XXXXX 
pattern...." is used repeatedly in these sections and their descendents. 
See comments about about need to refer to "schema documents", if that's 
what's intended.

* Sections 2.x:  The general form of the sections for patterns isn't 
clear.  Schema fragments seem to appear in blue, as do fragments of 
conforming instances, yet these examples have features that are unclear. 
For example, the sample for the "targetNamespace" pattern in section 2.1.1 

 is given as:

 <xs:schema
    targetNamespace="http://www.w3.org/2002/ws/databinding/examples/6/09/"
    elementFormDefault="qualified">
   <xs:element name="targetNamespace" type="xs:string" />
 </xs:schema>

yet the reason for declaring an element with the name "targetNamespace" 
isn't explained.  It seems that all sample schemas have an element 
declaration.  Why?  Explicitly specifying elementFormDefault is also 
confusing, since it doesn't seem to have to do with the pattern.  The 
schema:

 <xs:schema
  targetNamespace="http://www.w3.org/2002/ws/databinding/examples/6/09/">
 </xs:schema>

seems more appropriate for this pattern.  Similar comments apply to many 
of the binding patterns. 

* Section 2.1.2: talks about qualified local elements, but the sample 
schema contains no local elements.

* Section 2.1.6: BlockDefault.  This pattern seems to imply that 
substitutions and or derivations are blocked if the @blockDefault 
attribute is provided, but in fact that attribute carries a value that can 

selectively enable or disable blocking for any combination of extension, 
restriction, and substitution.  It seems unlikely that the rule of 
interest is really that the attribute is present.  Is that what's 
intended, or did you wish to actually check for certain values of the 
blockDefault.  Note, in particular, that an explicit blockDefault="" has 
the same semantic as leaving out the attribute entirely.

I regret that I did not have time to review the remainder of the patterns 
in the draft, but I would assume that the above comments would be 
representative of what would be found for other patterns.

Editorial Concern
-----------------

In addition to the concerns above, which represent the formal responses on 

 behalf of the Schema WG, let me make one more informal comment on my own 
behalf:

The databinding draft is very long, and a lot of it is devoted to what is 
ultimately boilerplate.  Consider the targetNamespace pattern.  It is 
introduced with nearly 1/2 page of multicolor writeup, but really all it's 

 trying to say seems to be:  This pattern requires that the schema 
document have a targetNamespace attribute with an absolute URI as its 
value.  That  could be said much more clearly and concisely.  I think the 
draft would be  much more effective if the patterns were introduced in a 
manner that was  as concise and clear as possible.   It's not helpful to 
repeat over and  over "An [XML 1.0] document exhibits....", and as noted 
above, the example  schema could be made shorter and clearer.  Finally, 
what would be most  helpful for a pattern like this is to explain ">>why<< 

an absolute URI"?  The Schema recommendation points to the XML Namespaces 
recommendation for  the definition of a namespace name, and that in turn 
requires a URI  Reference [5], not an Absolute URI.  So, it would be 
useful in general if  some of the boilerplate were eliminated and the 
sections made much shorter  and easier to read, but conversely it would be 

useful to say a bit about  what makes the pattern interesting.  Explain 
briefly if there's a reason  why absolute namespace URIs are interesting, 
or did you really just mean  this pattern to be "a non-absent 
targetNamespace is available"?

I (and we) hope these comments are useful to you in preparing future 
drafts of your Recommendation.  Thank you very much.

Noah Mendelsohn
for the W3C XML Schema Working Group

[1] http://www.w3.org/TR/2007/WD-xmlschema-patterns-20071031/
[2] http://www.w3.org/TR/xmlschema-1/#key-schemaDoc
[3] http://www.w3.org/TR/xmlschema-1/#gloss-src
[4] http://www.w3.org/TR/xmlschema-1/#key-schema
[5] http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-decl

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Friday, 15 February 2008 18:03:31 UTC