W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2006

[Bug 3816] Should we mention support for full Schematron in xsd:appinfo

From: <bugzilla@wiggum.w3.org>
Date: Sat, 14 Oct 2006 13:01:43 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1GYj95-0007vb-Jk@wiggum.w3.org>


cmsmcq@w3.org changed:

           What    |Removed                     |Added
             Status|NEW                         |ASSIGNED

------- Comment #1 from cmsmcq@w3.org  2006-10-14 13:01 -------
Speaking only for myself, I understood the point of requiring that processors
understand assertions made within appinfo, when it was first raised as a
possibility, as being tied to the plan that the assert and report elements, 
and the XPath expressions, supported in the one location (within a type 
definition) and the other (within appinfo) would be essentially the same.

We now have adopted a proposal for co-constraint assertions, however,
in which they would not be the same at all.

Support for Schematron in appinfo would involve supporting a different
version of XPath, and supporting the entire XPath language, and reading a 
different surface syntax.  So this is no longer a matter of saying "any 
conforming processor already has the ability to enforce these constraints, 
so recognizing them within appinfo is just a question of not ignoring them".  
Adding the requirement suggested by a 'yes' answer to the question in the 
summary amounts to adding a non-trivial implementation burden, a largeish
part of it devoted to recreating, with a different version of XPath,
functionality substantially similar to that of the assertions now in 1.1.  
Adding it not as a requirement but as a suggestion does not seem to me 
to serve any purpose, except to call attention to the differences in 
expressive power between the assertions now in 1.1 and those expressible 
with an unrestricted form of XPath.

Endorsing support for Schematron assertions in appinfo would make sense 
if conforming implementations supported them outside of appinfo.  But
given that what we have is not Schematron at all, endorsing Schematron
in appinfo only raises the question:  why not endorse this or that other
language for expressing constraints in appinfo?   

So (speaking for myself), I do not see the point of this proposal, and
suggest the WG not adopt it.
Received on Saturday, 14 October 2006 13:01:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:05 UTC