Databinding comments

I did a read of the databinding spec, and have a few surface-level comments.

 

1)      It's not clear to me why the XPath assertions are so complicated.
For instance, the following pattern:
    .[@targetNamespace]/ (., @targetNamespace)
returns a non-empty node-set (an xs:schema element and a targetNamespace
attribute) on a pattern-conforming schema.  However, a simpler pattern will
give us a similarly non-empty node-set:
    @targetNamespace
or if you really think this helps set the context (I don't), it's synonym:
    ./@targetNamespace
IMO this is simpler to read is that it is familiar to XPath 1.0 users, not
just those who dive into the (distressingly complex) XPath 2.0 spec.  There
seems to be additional information encoded in the XPath 2.0 form, but it's
not clear what it's used for, if anything, especially since this style
doesn't appear in all patterns.



2)      Pattern 2.1.4 SchemaVersion.  How does the version attribute help
with databinding?  Seems like encouraging it's appearance (while not a bad
idea) is orthogonal to the goal of mapping to data structures.  Same can be
said of 2.2.1 DocumentationElement, probably others as well.  This seems to
stray into general purpose schema subset territory.



3)      Pattern 2.2.1 DocumentationElement.  Listing <xs:annotation> twice
(in context and out) looks like a bug in the example generation code ;-).



4)      The patterns are written in terms of "a document exhibits a pattern
when .".  An effect of this is that a pattern may return a node-set even
when parts of the document don't exhibit the pattern, or exhibit the
opposite of the pattern.  For instance 2.3.3 NotMixed says a document
exhibits a pattern when there is at least one instance of @mixed="false",
but the information a user is most likely to want is whether the schema
exhibits any undesirable patterns, such as the (likely problematic)
@mixed="true".  In essence, the granularity implied with the statement "An
[XML 1.0] document exhibits the NotMixed pattern" doesn't seem to be
terrible useful, and contrary to the name, does not ensure a schema doesn't
allow mixed content.  It might be as simple as changing the expression to
something like @mixed!='true', or there might be a larger problem with the
granularity here.



5)      Appendix C why is R2800 not grouped with R2112?  They seem to be
introduced the same way.

 

Jonathan Marsh - http://www.wso2.com <http://www.wso2.com/>  -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com