- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 07 Oct 2009 20:31:07 +0000
- To: www-xml-schema-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7695 Noah Mendelsohn <noah_mendelsohn@us.ibm.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |noah_mendelsohn@us.ibm.com --- Comment #1 from Noah Mendelsohn <noah_mendelsohn@us.ibm.com> 2009-10-07 20:31:06 --- In doing a bit of looking at this issue, I was struck by what may or may not be better tracked as a separate concern. Specifically is the intended distinction (if any) between minimally conforming processors (a term formally defined in section 2.4), and "conforming" as used in the preamble to Appendix C.1, a clear one? FWIW: my recollection is that in XSD 1.0, we introduced the term "minimally conforming" to distinguish those implementations that are schema processors at all from those that are not. All our other conformance levels were described as being minimally conforming + having some other features. So, if your processor wasn't at least minimally conforming, our spec didn't provide conformance req'ts for you. Section C.1 now has statements like: "...the information set taken as input is augmented in the course of schema-validity assessment. Conforming processors may provide access to some or all of this information..." Note also that in 2.4 we say: "[Definition:] Minimally conforming processors must completely and correctly implement the ˇSchema Component Constraintsˇ, ˇValidation Rulesˇ, and ˇSchema Information Set Contributionsˇ contained in this specification." That is a bit ambiguous, but at least suggests that the whole PSVI be exposed by a minimally conforming processor. Taking the two quotes together, I think one concludes that either (1) there are processors that are conforming but not minimally conforming, which seems strange to me or (2) the presentations in 2.4 and C.1 were never reconciled. I think that cleaning this up is relatively easy, and doing so is likely to give us a slightly cleaner backdrop against which to consider MK's concerns. I think I could live with either of the following resolutions, both of which collapse the two terms into one. Either: A) In section 2.4 change the text to read "Minimally conforming processors must completely and correctly implement the ˇSchema Component Constraintsˇ, ˇValidation Rulesˇ, and, >optionally, some or all of the< ˇSchema Information Set Contributionsˇ contained in this specification."" Change section C.1 to read: "...the information set taken as input is augmented in the course of schema-validity assessment. >Minimally conforming< processors >MAY< provide access to some or all of this information..." -- or -- B) Get rid of the term minimally conforming completely. In its place, make "conforming processors" a termdef" in section 2.4, and change the text to read ">All< ˇconforming processorsˇ must completely and correctly implement the ˇSchema Component Constraintsˇ, and ˇValidation Rulesˇ. >Additionally, conforming processors MAY report some or all of the< ˇSchema Information Set Contributionsˇ contained in this specification. >(See Appendix C.1)<"" No changes to C.1. Optionally: add a note indicating that the term "minimally conforming" has been retired, but that where an equivalent is needed, readers should look to the XSD 1.1 conformance constraints placed on "all conforming processors" I have no strong reference between (A) and (B), and I'm open to other simple resolutions, but I do think this is worth cleaning up. The above suggestions are not meant to directly address MK's concerns, with which I have at least some sympathy, but rather to suggest cleanup that's worth doing in any case. I think we'll have an easier time considering Mike's request if the underlying exposition is a bit cleaner. Thank you. Noah P.S. I couldn't quite decide if this was better reported as a separate bug. Feel free to move it if you prefer, to ask me to resubmit. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 7 October 2009 20:31:08 UTC