This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Minor comment #3 in http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2008Mar/0001.html In 4.3.1.1, point 4 Namespace Binding Context -- not clear which 'containing element' is being referred to, suggest "element owning the sml:ref attribute" or something similar.
resolution (3/13 conf call): The text in LC does not use 'containing element'. Check with Henry if the current text addresses his concerns. For quick reference the current text is copied below: 4. Namespace Binding Context: The smlxpath1() scheme inherits the set of namespace bindings available to the parent sml:uri element. --- The SML WG believes that the current text in the LC draft resolves this issue fully. I'm changing its status accordingly. The change in status should cause email to be sent to the originator of this issue, to whom the following request is addressed. Please review the current LC text and let us know if you agree with this resolution of your issue, by adding a comment to the issue record. Or, if you do not agree with this resolution, please add a comment explaining why. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.
Sigh. "the parent" of what? The attribute containing the URI with the smlxpath1(), right? But attributes don't have parents, they have owners.
You made at least one light bulb burn brightly there, Henry. I read 'parent' just fine wrt attribute because I'd recently been poring through XPath 1.0, where that is indeed the relationship between attribute nodes and the element nodes they annotate in the markup. See http://www.w3.org/TR/1999/REC-xpath-19991116#dt-parent Which spec uses/defines the 'owner' relationship between those same two entities? Xpath 1.0 points to DOM as being different, but http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#ID-637646024 says nothing about an owner relationship (having searched, not browsed). Since these are older specs, it's possible the community has seen noted the terminological discrepancies and converged on something consistent. If this is the case, I suspect the wg would certainly consider using it given a ptr to same.
You're right, of course, the terminology isn't stable or consistent. It's the Infoset spec. which uses owner, 'owner element', to be precise: see http://www.w3.org/TR/xml-infoset/#infoitem.attribute
resolution (5/15 conf call): Use the term "owner" and reference the definition at http://www.w3.org/TR/xml-infoset/#infoitem.attribute; also add decided, editorial keywords. The SML WG agrees with the suggestion. We will change the text as suggested. I'm changing its status accordingly. The change in status should cause email to be sent to the originator of this issue, to whom the following request is addressed. Please review the resolution and let us know if you agree with it by adding a comment to the issue record. If we do not hear from you in the next two weeks, we will assume that you agree with the WG decision.
Resolution in 5/29 call - reopen the bug so that it can be fixed as per Comment #5
The smlxpath1() encoded fragment appears in the content of the sml:uri element. It does not appear in an attribute of the sml:uri element. Therefore, the term 'parent' is correct as used. The current text is copied below for quick reference: 4. Namespace Binding Context: The smlxpath1() scheme inherits the set of namespace bindings available to the parent sml:uri element.
Given an example (to remind everyone of the SML URI syntax) <foo sml:ref="true"> <sml:uri>http://www.example.org/someDocument#smlxpath1(/fred)</sml:uri> </foo> My _skim_ of http://www.w3.org/TR/xml-infoset/#infoitem.character http://www.w3.org/TR/xml-infoset/#infoitem.element http://www.w3.org/TR/xml-infoset/#infoitem.attribute is that the entire URI value "http://www.example.org/someDocument#smlxpath1(/fred)" is a sequence of one or more character information items, whose parent is the "<sml:uri>" element information item. Thus, as Kumar points out, the current text (which has changed since the bug was opened due to other bugs) uses terminology that appears to be consistent with the infoset spec. It appears though that 4.3.1 SML URI Reference Scheme bullet 1 does refer to sml:ref as a child of the SML reference element (here, "<foo>") which is inconsistent with the same spec. This is true in the Jan, March, and current editor's draft: An SML reference is identified as using the SML URI reference scheme if and only if exactly one element information item whose [local name] is uri and whose [namespace name] is http://www.w3.org/2008/03/sml is present as a child of that reference element. It appears that we would want to change from: is present as a child of that reference element. to : is owned by that reference element. The editors should probably scan both specs (Core, aka SML, being the more likely) for other instances where attributes are called children, as well.
As was pointed out during the call, 4.3.1 item 1 is talking about sml:uri, not sml:ref, so the existing text IS consistent with Infoset. just read it too fast ... sigh
resolution (6/12 conf call): This has been fixed in the current draft The SML WG agrees with the suggestion. We will change the text as suggested. I'm changing its status accordingly. The change in status should cause email to be sent to the originator of this issue, to whom the following request is addressed. Please review the resolution and let us know if you agree with it by adding a comment to the issue record. If we do not hear from you in the next two weeks, we will assume that you agree with the WG decision.
I am happy with this fix.