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.4.6-Resolving Inter-document References says that references containing only fragments must point to the document in which they occur. But section 3.4.5- Relative Reference above requires a [base URI] to be specified for any relative reference : If any inter-document reference or any alias of any document in the interchange set is a relative URI, then the [base URI] property as defined by Infoset [XML Information Set] MUST be used to specify a base URI for these references. Issues: 1. A URI fragment is also a relative URI so 3.4.5 must apply to fragments. By doing that is quite possible that the URI resulted by applying the [base URI] to that fragment to be equivalent with a document alias in the IF set. Which means the fragment may point to outside documents Possible resolutions: 1. fragment URIs are not required to have [base URI] defined (update 3.4.5 to say that). They always point to the document containing them. If a [base URI] is defined at instance document level, within the document containing the fragment, and the [base URI] applies to this fragment, there should be no attempt to match the resulted URI with a document alias in IF. If a [base URI] is defined globally, at the IF level, this [base URI] should not be applied to fragments. In other words, resolution 1 says that fragments are always pointing to the same document containing them. 2. Fragments behave just like any other relative URI. The only difference is that they are not required to have a [base URI] specified since they may be just references pointing to the same document. If [base URI] are specified, locally or globally, fragments are required to observe them; as a result fragment identifiers MAY and up pointing to documents other then the one containing them.
Sample A sample fragment which after normalization can be equivalent with a document alias other then the one containing the fragment ( and as a result, the fragment can be an inter-document reference pointing to a different document): <?xml version="1.0" encoding="UTF-8"?> <model xml:base="http://www.sample/a/"> <instances> <document> <docInfo> <aliases> <alias>b/instance1.xml</alias> </aliases> </docInfo> <data> <Courses xml:base=c/instance1.xml> ... <sml:uri>#xpointer()</sml:uri> </Courses> </data> </document> <document> <docInfo> <aliases> <alias>c/instance1.xml</alias> </aliases> </docInfo> </document> </instances> </model> document 1 alias after baseURI normalization : http://www.sample/a/b/instance1.xml document 2 alias after baseURI normalization : http://www.sample/a/c/instance1.xml fragment in doc 1 after baseURI normalization : http://www.sample/a/c/instance1.xml#xpointer(...) << this is equivalent with doc 2 alias
3.4.5 ...then the [base URI] property as defined by Infoset [XML Information Set] MUST be used to specify a base URI for these references. I believe this is in error, opened 5181 for it earlier today. Should be /model/identity@xml:base in particular. Proposal: Clarify the text (doing so may take several iterations) without changing the original intent, namely: 1. A model has a single base URI for relative references 2. Fragment-only references are always treated as what RFC 3896 calls "same-document references" where "same-document" means the model definition/instance document in which the reference is logically embedded (we do like our recursive definitions). Put another way, it is treated as if the SML-IF envelope was absent and no other base URI existed in the infoset. According to RFC 3896 same-doc refs are relative (because they do not begin with a scheme followed by a colon), but SMLIF is asserting a different application-defined base URI for what it calls fragment-only [inter-doc] refs than for relative refs in general. In practice this probably means refining the reference resolution "code" from Sandy's proposal to make this explicit, and given the varying interpretations around base URIs and relative references already in evidence between here, 4688, and 5181, the group probably should see the revised code before it is committed to a new draft.
An offline question led me back to [XML Base]. SMLIF (when it had baseURI defined) restricted the value to an absolute URI. We would need to keep that constraint, applied to /model/identity@xml:base's value, in order to revert to the originally specified function. Absolute URIs are defined in RFC 3896, the main difference being they must have a scheme (so they are not relative) and must not have a fragment.
Wait for Sandy's proposal
*** This bug has been marked as a duplicate of bug 5181 ***