http://www.w3.org/Bugs/Public/show_bug.cgi?id=3816cmsmcq@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.