[Bug 4788] Change all usages of URI to URI-reference which includes both absolute and relative forms of URIs.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4788





------- Comment #7 from johnarwe@us.ibm.com  2007-11-15 17:04 -------
Ginny is correct in comment 6 about the intent of this bug.  Scanning the
editors drafts for URI myself, I find more than 2 places to change. Since I am
doing this, I am also generalizing the bug to fully align with RFC 3986
terminology; anyone disliking that can ignore the extra changes listed here or
move them into a separate bug.

4.1 Packaging, the example (2 places)
from: "...smlerr:localizationid=xs:anyURI URI           identifying the
translation resource..."
to:   "...smlerr:localizationid=xs:anyURI URI reference identifying the
translation resource..."

4.1 Packaging, the example (2 places)
from: "...<alias> * xs:anyURI An          URI by which..."
to:   "...<alias> * xs:anyURI An absolute URI by which..."

4.1 Packaging
from: "...Each of these          URIs serves as a name ..."
to:   "...Each of these absolute URIs serves as a name ..."

4.1 Packaging
from: "...Typically it is a URI          , an XLink..."
to:   "...Typically it is a URI reference, an XLink..."

4.2 Interdocument References
from: "...If the URI           in such a                reference is equivalent
..."
to:   "...If the URI reference in such an interdocument reference is equivalent
..."
(I realize this collides with the much-anticipated idr proposal, can be moved
into one of those bugs so it is not changed twice w/o objection from me)

4.2 Interdocument References (2 places)
from: "...is equivalent to the          URI in an alias..."
to:   "...is equivalent to the absolute URI in an alias..."
(ditto, possible collision)

- several more spots where naked "URI" is used around aliases elided

4.2 Interdocument References 
from: "...written as a relative reference,     URI           coming..."
to:   "...written as a relative reference, the URI reference coming..."

4.2 Interdocument References 
from: "...The other URIs           in the example..."
to:   "...The other URI references in the example..."

5.3.1 URI equivalence
from: "...To determine whether two URIs           are equivalent..."
to:   "...To determine whether two URI references are equivalent..."

5.3.1 URI equivalence
from: "...corresponding characters in the URIs          . ..."
to:   "...corresponding characters in the URI references. ..."

5.3.1 URI equivalence
from: "...relative URI       is tested for equivalence with another URI..."
to:   "...relative reference is tested for equivalence with another URI..."
Note that here we actually have several specification problems.  I suspect we
want them in a separate bug, but I will list them here to get feedback on
whether or not to open a new bug.
- This text talks about comparing relative refs.  RFC3986 6.1 says relative
refs should not be directly compared; they should be converted to their target
URIs and the target URIs should be compared.
- Relative refs have an optional fragment component.  When we are doing alias
checking and use URI equivalence, there are two ways to look at it, but neither
are discussed directly:
  1. We first find the document, by comparing target URIs _after removing_ any
fragment component, and then separately compare the fragment components if any
of the document URIs are equivalent.
  2. For any given ref, we generate a series of target URIs by taking each
document alias in turn and appending the sml ref's fragment component to it,
and compare each of those to the relative ref's target URI.
Essentially, read strictly as currently written, an alias (always absolute URI
which implies NO fragment component) would NEVER match any URI ref containing a
fragment component.  5.3.5 is also contaminated.

5.3.3 Document aliases
from: "...Each alias contains a           URI. ..."
to:   "...Each alias contains an absolute URI. ..."

5.3.4 Relative references
from: "...set is a relative URI      , then the [base URI]..."
to:   "...set is a relative reference, then the [base URI]..."

5.3.5 Resolving Interdocument References
from: "...If the URI           representing..."
to:   "...If the URI reference representing..."

5.3.5 Resolving Interdocument References
from: "...if the URI           representing an interdocument reference ..."
to:   "...if the URI reference representing an interdocument reference ..."

5.3.5 Resolving Interdocument References (2 places)
from: "...If the URI           representing..."
to:   "...If the URI reference representing..."

5.4.1 URI prefix matching
Whole section is ambiguous.  As written, fragment components appear to be
allowed and any fragment component would be part of the comparands, which I
doubt is what we want.  This could be spun off to a separate bug.

Finally, this bug is targeted at SML only, but similar issues do exist in SMLIF
(I just checked the editors' copy).  Would folks prefer enumerating them here,
or in a new separate bug?

Received on Thursday, 15 November 2007 17:04:54 UTC