Note, editor should be careful to create a diff document for the changes for this bug and only the changes for this bug!

from IRC - RESOLUTION: move to editorial, any changes need review, take the following approach (1) replace URI with URI reference, (2) replace relative URI with relative reference, (3) insert absolute whenever we mean absolute URI.

If any URI usage is unclear or not covered above, come back to the group (preferably with proposal) to decide correct term.

The only two places in the SML spec that uses the term URI other than in the context of 'URI Scheme' is in Section 4.1:
2.	An extensibility mechanism allowing new reference schemes to be defined, conceptually similar to the relationship between URI references and URI schemes. 

and in Section 4.2.1:
and each document has an associated URI:
which I believe should not be changed to 'relative URI'.

I agree with the changes listed in comment# 2.

I am in favor of deleting the last part of the sentence in 4.1 since it may give a wrong impression that somehow reference schemes are always based on URIs.

Specifically, change,

from: 2. An extensibility mechanism allowing new reference schemes to be defined, conceptually similar to the relationship between URI references and URI schemes.
to  : 2. An extensibility mechanism allowing new reference schemes to be defined.

Agree with comment #3.

Regarding the 2nd change in comment #2. Below the sentence "...and each document has an associated URI" is a table with absolute URIs. Based on the resolution (comment #1), shouldn't we change "...and each document has an associated URI" to "...and each document has an associated URI reference"?

I'm certainly open to that possibility if the group agrees it should read that way. Here's my line of thinking: As it is used in this sentence (in Comment #2) I believe a document is associated with a URI 'out there on the web'. If we use that URI to refer to the document, such as in an SML document, it is a URI reference, which is what I believe we were saying in the resolution. We can certainly vote on it and change it if necessary.

This bug is not about SML references (or document references) but is only about using the correct terminology for URIs as defined in RFC 3986 which states:
"4.1.  URI Reference

   URI-reference is used to denote the most common usage of a resource
   identifier.

      URI-reference = URI / relative-ref

   A URI-reference is either a URI or a relative reference.  If the
   URI-reference's prefix does not match the syntax of a scheme followed
   by its colon separator, then the URI-reference is a relative
   reference."

At the time this bug was submitted, many of the examples used relative references but the text referred to them as URIs. Philippe pointed out (see 6/12/07 minutes) that we cannot (correctly) refer to a "relative URI" using only the term "URI". But, if we use the term 'URI reference', then we are using correct terminology regardless of whether we are talking about absolute or relative URIs. Thus, it was decided that we should use the term URI reference so the terminology would be correct in all cases. For example, we wouldn't have to change the text if suddenly an example is changed by replacing a relative reference with a URI or vice-versa.

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?

sorry, ignore comment 7 had submission level of specs open

Resolution: ok as is.