This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At one point there was discussion of having a note or appendix which would suggest that, in addition to supporting our normative constraint checking features, processors be encouraged to support (full?) Schematron in xsd:appinfo. This issue is being suggested to remind us to discuss the possibility of such a note or appendix. Noah
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.
During today's call, the Working Group decided against taking action on this issue, and to close it with the disposition WONTFIX. That means that we do not expect any change in the 1.1 spec to address the concern raised here. (In view of the tight time frame, this decision may be reopened and revisited on next week's call.) Accordingly, I'm marking this issue as resolved. Noah, as the originator of this issue, you can signal your agreement with (or at least: acquiescence in) this decision by marking the issue CLOSED, or you can indicate your dissatisfaction with the decision by changing the status to REOPENED. If we don't hear from you in a couple of weeks, we'll assume you acquiesce and the issue will be marked CLOSED.