|
+1
I
think Loren's understanding is reasonable and should be the approach of the TC.
Comments are removed for the purposes of equivalence &
normalization (this is my understanding - which I do not know we have
discussed) so the case sensitivity issue is not impacted here because case
sensitivity is a normalization/equivalence rule. The wording needs to be
explicit. This assumes we agree on the "comment" mechanism, which we have not
yet agreed to.
Little
Quibbles:
We
have to be careful with the wording "manager of each namespace" - a concept I'm
not sure we've discussed before. This is a quibble - we can reword this in the
terminology and conceptual framework of the current spec. Also the "byte
for byte" equivalence statement should probably be "character for character
after NFC normalization" (which I believe it is now).
-Gabe
Hi
TC'ers,
I
agree with Mike except for the comment portion of the XRI. Maybe the
spec. should read:
Two
XRIs are equivalent if the NON-COMMENT portions of the XRIs are byte-for-byte
equivalent.
That being the normative part of the spec. At this point, some
people may mis-interpret the intent (as I did), so maybe a discussion of case
sensitivity in regards to resolution should follow
(non-normative):
During resolution, the manager of each namespace may have their own
rules for case sensitivity and equivalence in general.
One namespace owner might consider "Invoice" and "invoice" to be the same
for the purposes of resolution. Another may consider "grey" and "gray"
to be the same. Since you can't know that without invoking the
resolution process, they should be considered different XRIs that happen
to point to the same resource.
Obviously, this is a sensitive issue :-)
=Loren
Hi
All,
I'd like to follow up on the case-insensitivity
issue and mention what I see as a reasonable example that would argue
against case-insensitivity. In my experience, the vast majority of my
accounts/login IDs on various systems are case sensitive. Also, in
unix-based systems (and many others), most identifiers (anything in the
file system for sure) are case sensitive. If any of
these identifiers are to be used in XRIs, the case-sensitivity
would need to be maintained, or ambiguity would be
introduced.
Between this issue and the Unicode issue, it seems
to me that it would be a bad idea to try to make any part of an XRI case
insensitive.
Mike
Case insensitivity is a form of normalization that a large
population of people receive benefit from. If there's a way to
provide that benefit to those people without degrading functionality where
it doesn't make sense, then I think we should do it.
I'd hate to see case insensitivity for ALPHA characters go
away.
=LOREN
-----Original Message-----
From:
Dave McAlpin [mailto:dave.mcalpin@epokinc.com]
Sent: Thursday,
September 04, 2003 11:06 AM
To: 'Sakimura, Nat'; 'Wachob, Gabe';
xri@lists.oasis-open.org
Subject: RE: [xri] Draft -07 feedback
from another Visa person (responses cont'd)
So are we OK
with case-insensitive comparison for ALPHA characters in the authority
component, or should we drop this altogether?
-----Original
Message-----
From:
Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
Sent: Thursday, September 04, 2003
10:57 AM
To: Dave
McAlpin; Wachob, Gabe; xri@lists.oasis-open.org
Subject: RE: [xri] Draft -07
feedback from another Visa person (responses cont'd)
I do not think
that there is a good way of introducing “case insensitivity” to Unicode
in general.
Case
insensitivity is a form of normalization, which is very problematic for
the international character set. IMHO, only meaningful form of general
equivalence is the bit to bit comparison or the comparison of the
resolved result from the same authority.
Nat
-----Original
Message-----
From: Dave
McAlpin [mailto:dave.mcalpin@epokinc.com]
Sent: Friday, September 05, 2003
2:43 AM
To: 'Wachob,
Gabe'; xri@lists.oasis-open.org
Subject: RE: [xri] Draft -07
feedback from another Visa person (responses cont'd)
|