This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 3.3.1.1, "Fragment Identifier", specifies that when the URI reference method is used, fragment identifiers must use the xmlns() and xpointer() schemes defined within the XPointer framework. At the face to face meeting in Redmond (June 2007), some WG members suggested that the SML spec really shouldn't talk about that level of detail, and that 3.3.1.1 should be deleted. Others felt that it should be retained, if not necessarily in its current form, and that logical completeness in the description of the URI spec demands that we have SOMETHING to say about fragment identifiers. (Web architecture says that fragment identifiers depend on MIME types -- what MIME types do the documents in an SML model have? TBD.) Several questions seem to be deeply intertwined here: 1 Should we say anything at all about fragment identifiers? 2 Should we specify that fragment identifiers should fit within the XPath framework? 3 Should we require that all SML processors who support the URI reference method [scheme] must support some specific set of fragment identifier schemes? (As in the submission, which requires that xmlns() and xpointer() be supported.) In other words -- what is the floor on which any producer of SML data may rely? It was noted that in principle processors aren't required to support the URI scheme in the first place; some WG members felt this meant trying to require certain fragment schemes was doomed to unhelpfulness from the outset, while others felt that setting some sort of floor would be nonetheless useful. 4 Should we require that all SML data which use the URI reference method [scheme] must formulated their fragment identifiers using some specific set of fragment identifier schemes? (As in the submission, which requires that xmlns() and xpointer() be used.) In other words, what is the ceiling which limits what schemes may be used in SML data or supported by SML software? There was some sentiment for allowing any pointer scheme compatible with the XPointer framework. 5 Assuming we say anything at all, what should be said in the SML spec and what should be said in the SML IF spec? There was some sentiment for putting most of the detail into the IF spec and saying just enough in SML to achieve logical completeness.
Proposal: Remove all references to the xpointer framework and the associated schemes from the SML/SML-IF spec. Define sml:uri scheme such that its fragment identifier is encoded using XPath 1.0 location path (http://www.w3.org/TR/xpath#location-paths) as shown below: SMLURI = URI (# XPath1.0_LocationPath)? In this scheme, if the fragment id is missing the reference points to the root element of the target document. If the fragment id is present, the root element is the context node to which the path is applied. Reasons: The Xpointer framework is a w3c standard but it has not found sufficient support from the industry and the community. In fact, the members of the original xpointer working group themselves have come up with a competing proposal (fixptr), but that is not a w3c standard. Although the xpointer() scheme offers more powerful semantics (such as string-range, start-point, etc.) they are of no use for identifying target elements. Moreover, the xpointer() scheme is not a w3c recommendation. There are only 2 xpointer schemes that are w3c standard: element() and xmlns(). The element scheme is very brittle. For example, element(/3/5/1) denotes the first child of the fifth child of the third child of the root element. A simple change to a document can invalidate many references or worse, keep them valid and change the target silently. The xmlns() scheme is used for declaring XML namespace prefixes and it not used for identifying elements. The primary purpose of the fragment identifier in an SML reference is to identify the target element. This need is adequately met by using xpath. XPath 1.0 is already used by SML validators and thus the use of xpath in fragment identifier will not put any additional burden on implementers.
*** Bug 4872 has been marked as a duplicate of this bug. ***
Based on minutes from Redmond f2f, Oct 16, I moved this back to unassigned and set keyword to needsAgreement only: From minutes: "Created ACTION-135 - Investigate if there any implemetation issues with supporting xpath1() scheme [on Kumar Pandit - due 2007-10-23]. Resolution: get back to this defect after Kumar and Pratul/John/MSM investigates issues with the proposed xpath1() scheme usage"
I investigated the URI fragment issue by reading the relevant specs, MSDN articles and other sources. Here is the summary of what I found. We have 2 options: 1. Define our own way of encoding fragment identifiers. This is defined in an earlier comment, therefore I am not repeating it here. a. Pros: i. Simplicity ii. We fully control the definition. iii. Namespace binding context is same as that of the containing element. This means that namespace binding can be reused across multiple references. Increases the readability of a model. iv. Very little implementation impact since an SML validator already has to support xpath 1.0. b. Cons: i. Politically wrong approach according to Michael. 2. Use xpointer framework in combination with a profile of the xpath1 scheme. a. Pros: i. Politically right approach according to Michael b. Cons: i. We will take normative dependence on something that is not a W3C recommendation. (Michael to find out if this is allowed/discouraged by W3C. Not sure how it balances against 2.a.i.) ii. xpath1 scheme allows full xpath 1.0 expressions plus some additional extensions. We only need a limited ability to address elements. The WG needs to spend time defining the profile. iii. We do not completely control the definition. Although we will create a profile, the underlying definition can potentially change. The likelihood of this is low but we cannot rule it out. iv. The xpath1 scheme normatively requires support for xmlns() scheme. The namespace binding context must be set using xmlns() scheme. It cannot use the namespace binding context of the containing element. For example, even if xmlns:x=http://x.com and xmlns:y=http://y.com have been defined for an element, if it uses xpath1 scheme (or other xpointer() schemes), it must repeat the bindings as follows: <sml:uri>baseuri:/a/b.xml#xmlns(x=http://x.com) xmlns(y= http://y.com) xpath1(/x:e1/y:e2)</sml:uri> compare that with: <sml:uri>baseuri:/a/b.xml#/x:e1/y:e2</sml:uri> The namespace bindings must be repeated for every xpointer instance. This can quickly get very unreadable. v. To be fair, the above can be partially solved by using the xmlns-local() scheme but that scheme is not a W3C rec. either. vi. Implementation impact: 1. Must implement Xpointer framework related parsing (as defined by BNF in the xpointer framework). 2. Must implement Xpointer framework related escaping mechanism. 3. Must implement xmlns() scheme. 4. The Microsoft .net framework does not support any of the above, thus has impact on the Microsoft SML implementation. I have not considered some of the other options we discussed such as we forming a sub-group to move xpath1 (or our own schme) through the W3C process to recommendation. I think that introduces too much uncertainty on SML schedule.
Proposal: Define our own scheme based on the xpointer framework. The scheme is defined as follows: 1. Scheme name: smlxpath1. 2. Scheme BNF: SML_Fragment_ID = smlxpath1 ( XPath1.0_LocationPath ) 3. sml:uri BNF: SMLURI = URI (# SML_Fragment_ID)? 4. Namespace binding context: The smlxpath1 scheme inherits the set of namespace bindings available to the containing element. Reasons / More info: 1. We do not have to take normative dependence on schemes that are not w3c Recommendations. 2. We do not have to spend considerable time defining a profile of some other scheme. 3. Implementation impact: a. Must implement Xpointer framework related parsing (as defined by BNF in the xpointer framework). b. Must implement Xpointer framework related escaping mechanism.
Resolve as per Comment #5
Adding comment from meeting minutes: Resolution: as per comment #5, and clarify that the deref() function is not in the expression evaluation context function library for smlxpath1 expressions
The following changes were made: ---- Removed text related to xpointer() scehem and its profile definition. ---- added the following to 4.3.1 SML URI scheme definition. 4. Scheme syntax: SMLURI ::= URI ('#' SMLXPath1_Fragment_ID)? where , URI is a URI reference without a fragment identifier. SMLXPath1_Fragment_ID is a production that defines the syntax of the fragment portion of the SML URI scheme. This is defined in section 4.3.1.1 The smlxpath1() scheme. ---- added section 4.3.1.1 4.3.1.1 The smlxpath1() scheme The smlxpath1() scheme is intended to be used with the XPointer Framework [XPointer] to allow addressing of elements. The 4.3.1 SML URI Scheme uses it to encode fragment identifiers. This section describes the syntax and semantics of the smlxpath1() scheme and the behavior of XPointer processors with respect to this scheme. 1. Scheme name: smlxpath1. 2. Scheme syntax: SMLXPath1_Fragment_ID ::= 'smlxpath1' '(' SMLXPath1_SchemeData ')' SMLXPath1_SchemeData ::= XPath1.0_LocationPath where, XPath1.0_LocationPath is the LocationPath production defined in the XPath 1.0 specification [XPath]. 3. The deref() XPath extension function MUST NOT be present in the expression evaluation context function library when processing the location path in SMLXPath1_SchemeData. 4. Namespace Binding Context: The smlxpath1() scheme inherits the set of namespace bindings available to the containing element. 5. Document Context: The document context is set by the URI reference containing the smlxpath1() scheme instance. 6. The element(s) targeted by a scheme instance are obtained by applying the location path in SMLXPath1_SchemeData to the root element of the document in the document context. The result MUST be a set of elements. The set MAY be empty. If the result of applying the location path is something other than an element or an element-set, then the XPointer result is an error. ---- Updated the example that previously showed xpointer() scheme usage.
If I have <myref> <sml:uri>#abc(xyz)</sml:uri> </myref> Then it's clear that it doesn't satisfy the syntax. But it's not clear what's the consequence: is <myref> not recognized as an instance of the URI scheme, or should it be an error? I think the latter is intended, in which case the new bullet 4 in section 4.3.1 can benefit from a "MUST". e.g. something like: Content of the sml:uri element MUST be valid with respect to the xs:anyURI type and it's normalized value MUST satisfy the following syntax ...
Changed the definition as suggested in comment# 9. ---- 4. Content of the sml:uri element MUST be valid with respect to the xs:anyURI type and its normalized value MUST satisfy the following syntax. ... syntax unchanged ... If the content of the sml:uri element is not valid with respect to the xs:anyURI type or its normalized value does not satisfy the above syntax then the scheme instance is in error.
If the result of applying the location path is something other than an element or an element-set, then the XPointer result is an error. Where is "element-set" defined? I do not see it in XPath 1.0. I wonder if you were thinking of node-set (which, incidentally, may contain more than just element nodes so it would not really fit here).
Rephrased the sentence mentioned in comment# 11 to eliminate the word "element-set". The new sentence is: If the result of applying the location path is something other than a set of elements, then the XPointer result is an error.
+1 to changes made for this bug.
+1 for applied changes