This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
3.13.2 XML Representation of Assertion Schema Components XML Mapping Summary for XPath Expression Property Record says "{base URI} The [base URI] of the host element. " I think your existing text is OK in its use of "host element" as a kind of "parameter" within your spec. I found no conflicting definitions at least. 1.4 Dependencies on Other Specifications simply lists Infoset as one of the dependent specs. Appendix E Required Information Set Items and Properties (normative) lists a number of infoset properties as being required [base URI] has not been added it appears, and should be given your XPath expression schema component definition, no? Not to mention schemaLocation issues from 1.0, where one might argue it should have been cited (if the timing was right wrt Infoset, but presumably it was) 4.2.2 Assembling a schema <include> clause 1 4.2.3 <redefine> clause 2 4.2.4 <override> clause 2 4.2.5.2 <import> clause 2 4.3.2 How schema definitions are located on the Web - item 3 If the schemaLocation value is a relative reference, what base URI is used to resolve it? [base URI] of the schemaLocation's parent element? 4.3.2 How schema definitions are located on the Web - item 3 "It is not an error for such an attempt to fail, ..." Given the requirement on <override> (MUST resolve), is the stmt above actually true as stated any more? I might argue the same for <redefine>. Both 4.2.3 <redefine> clause 2 and 4.2.4 <override> clause 2 seem to contradict the unqualified "is not" above. Note that some people have argued, very recently, that the lack of any dependency in Schema 1.0 on [XML Base], including indirectly via [base URI], is evidence of a lack of support for XML Base within W3C and grounds for not depending on XML Base in new specs. It would be helpful to be explicit about the handling of base URIs in Schema 1.1 at least, so we can proceed on to newer "discussions" :-)
The SML working group chose to endorse this bug on its call of 2008-09-11
The XML Schema WG discussed this issue at length during today's face to face meeting. In general, we are happy to make the appropriate changes and grateful to you for pointing out to us the need for them. Essentially, the three points of agreement on which we converged in today's discussion are as follows; please push back if these seem problematic. 1) The semantics of [base URI] are as described in the XML Base spec. This follows already from our reference to the Infoset spec (which says that [base URI] is calculated as specified in the XML Base spec), but we will add a note pointing out that our reference to the [base URI] property has the consequence that in XML input, xml:base can be used with the semantics describedin the XML Base spec. 2) The [base URI] property should be listed as one of infoset properties we depend on. This has been done already in connection with bug 5800. 3) Where we resolve relative URIs, they are absolutized using the [base URI] property of the relevant element, as prescribed by the XML Base spec. A detailed wording proposal will be prepared by the editors.
On 11/6 the SML working group endorsed the resolution in comment 2 without objection.
During its 2008-11-21 telecon, the schema WG adopted a proposal to address the third point in comment #2. The proposal (along with some other changes) can be found at (member-only): http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni.20081121.html With this change, the WG believes that all the issues raised in this bug report are addressed. I'm marking this RESOLVED accordingly. John, if you would indicate your concurrence with or dissent from the WG's disposition of the comment by closing or reopening the issue, we'll be grateful. If we don't hear from you in the next two weeks, we'll assume that silence implies consent.
changes look ok (in a document of this size, some hint as to which sections to look at for changes would be helpful) I realized in reading them that a sentence in appendix E is pretty opaque > For interoperability, processors should accurately reflect these properties of the input to validity assessment. "reflect"? My understanding of the intent is that the schema processor should expose "these properties" in the infoset resulting from validity assessment, but honestly I would not (reliably, for sure) attach that intent to the words without out of band knowledge. I encourage the editors to be less succinct in this case. "accurately" seems odd too, it hints at unseen dragons. Since my nominal options are reopen/close, I'll reopen to ensure this admittedly late comment is at least seen. In the interests of "full speed ahead", (a) I will not raise any formal objection over this no matter what the Schema wg decides to (not) do about it. If the wg decides to make no such change, it is free to close this bug unilaterally. (b) I will give you a concrete proposal for the editors: For interoperability, processors should behave as if these properties were copied from the validity assessment episode's input infoset to the resulting infoset. That is, the validity assessment episode's output infoset should expose these properties and their respective values should match the input infoset.
John, Thank you for the comment on the opening paragraph of appendix E, which for convenience I reproduce in full: This specification requires as a precondition for ·assessment· an information set as defined in [XML-Infoset]. The result of assessment may depend upon the following information items and properties. For interoperability, processors should accurately reflect these properties of the input to validity assessment. The second and third sentences were inserted in a recent revision of the text, in connection with the resolution of bug 5800 (for those who need them, the minutes of the relevant meeting are at http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2008Oct/0007.html). The editors have not checked with the Working Group yet, but our understanding of the sentence "For ... assessment" is that it means NOT (as I think you take it) For interoperability, processors SHOULD expose the following information items and properties in their representation of the PSVI (and do so accurately) of the document. but instead something more like For interoperability, processors SHOULD be careful to be accurate in establishing the values of the following information items and properties (since the result of assessment depends on them). The problem may lie in the verb "reflect", which was chosen to allow the text to get rid of the verb "support" (which one WG member described as "always a weasel word") but which turns out to suffer from frailties of its own. I think the WG should choose among the following courses of action: 1) Adopt the wording proposed by John Arwe in comment 5, which replaces "For ... assessment" with: For interoperability, processors should behave as if these properties were copied from the validity assessment episode's input infoset to the resulting infoset. That is, the validity assessment episode's output infoset should expose these properties and their respective values should match the input infoset. This would entail an understanding of the text which differs radically from mine; in general, the XSD 1.1 spec works hard NOT to make any recommendations about what PSVI information is exposed by a conforming processor, and some WG members resisted even the proposal to provide names for some defined subsets in Appendix D.1, on the grounds that the names would be taken as recommendations. 2) Adopt the following alternative wording proposal, which replaces the entire paragraph with: This specification requires as a precondition for ·assessment· an information set as defined in [XML-Infoset] which contains at least the following kinds of information items and properties. This reverts to the wording of XSD 1.0, but replaces "supports" (which is vague, and also ill matched with "information set" as its subject) with "contains" (which is what an information set does to information items and their properties, in the usage of the infoset spec). 3) Delete the sentence "For ... assessment" to make the paragraph read: This specification requires as a precondition for ·assessment· an information set as defined in [XML-Infoset]. The result of assessment may depend upon the following information items and properties. From the fact that assessment results depend on the information items and properties mentioned, it seems clear already that interoperability depends on validators taking some care to get the values of the properties right. It is hard to imagine a reader benefiting from the explicit exhortation that validators SHOULD do so. For what it's worth, my own recommendation is 2, or 3.
The WG discussed the proposals by MSM in comment #6, and chose to decide the issue using option #2.
great, supah (nb: I'm not sure at this point if I should be marking it resolved, or if in the Schema wg that is done by the editors to help manage workflow, so I am leaving it re-opened. Feel free to resolve and close it once you are done with any work its existence signals a need for.)