OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Issue 1: Clarifying * Semantics


Title: RE: [xri] Issue 1: Clarifying * Semantics
In number 3, I meant to say "false negative". Sorry about that.
 
Dave


From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
Sent: Thu 7/8/2004 12:35 AM
To: Loren West; xri@lists.oasis-open.org
Subject: RE: [xri] Issue 1: Clarifying * Semantics

Here's my position.
 
1) Parsing is not significantly simplified under the proposal. There's essentially no difference in parsing between xri:@:1:2:3 and xri:@:1*:2*:3
 
2) Implied semantics still exist under the proposal - there's an implied * following a GCS character if the next subsegment is reassignable. If we really think people are confused by 1.0 syntax because there's no dot following a slash, I don't see why they're not equally confused by the fact that there's no * following =. In fact, the existing syntax isn't confusing. It's obvious what's meant by xri:@example/foo*bar, whether or not a star is technically allowed after the @ and / characters.
 
3) While it's true that the implied star provides a way to produce a false positive comparison (xri:@foo and xri:@*foo), it's an unusual case. An XRI processor concerned about that sort of corner condition is going to normalize for other things like unnecessary escaping. Removing unnecessary *s is trivial if you need to scan the XRI anyway.
 
4) XRIs with persistent segments become longer and harder to read. If we're going to do something that's human unfriendly, we need a strong justification.
 
5) The proposal breaks alignment with URN syntax. Right now you can take most URNs, append a resolution root and have an XRI. For example, urn:foo:bar:baz becomes xri:@:foo:bar:baz. Parallel syntax to a familiar form is a good thing.
 
The bottom line is that I don't see a compelling technical justification for the change.
 
Dave


From: Loren West [mailto:loren.west@epok.net]
Sent: Wed 7/7/2004 11:21 PM
To: xri@lists.oasis-open.org
Subject: RE: [xri] Issue 1: Clarifying * Semantics

This conversation of the similarity of ":" and "?"
has distracted from the main point of the message.

That is, the funky situations you point out aren't that
funky at all.  Epok has already written this so-called
funky code, and I'd be happy to talk to any developer
about writing code that handles these common situations.

I believe the specification is the way it is now because
it makes the identifier visually simpler at a low
(relatively insignificant) cost to the developer.

=Loren

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Wednesday, July 07, 2004 7:48 PM
To: Loren West; xri@lists.oasis-open.org
Subject: RE: [xri] Issue 1: Clarifying * Semantics


I don't understand how "?" can be considered both a
separator and a decorator. In XRIs just as in URIs
(where we got it), it's a separator that has a
syntactic meaning, just like "/" and "#". Under this
proposal "*" would be in this same class.

Colon, on the other hand, would be ONLY a decorator.
It would NOT be both a separator and a decorator as it
is currently.

That is the key point of this proposal. As Gabe
explained, in XRI 1.0, dot and colon both served dual
roles as separators AND decorators. That led to two
funky situations:

1) It requires that we define an implicit dot before
any reassignable segment that doesn't actually require
dot as a separator, and

2) It requires that when colon is used after "/" or a
GCS character, it NOT be interpreted as a separator,
but only as a decorator.

By separating the role of separator from decorator,
this proposal solves both problems cleanly.

=Drummond


--- Loren West <loren.west@epok.net> wrote:
&gt; On the topic of parser simplicity, three people
&gt; on this list, all of whom have actually written a
&gt; parser
&gt; believe that it's just as simple one way or the
&gt; other.
&gt;
&gt; I believe we haven't heard from anyone who's
written
&gt; a parser because they'd be hard pressed to
describe
&gt; why
&gt; there's a significant difference.
&gt;
&gt; Combining separation and decoration
characteristics
&gt; is
&gt; a well established pattern in identifiers and
&gt; parsing.  We use
&gt; that pattern elsewhere in XRI with the "?"
character
&gt; which serves
&gt; as both a separator and decorator.  I believe
with a
&gt; single
&gt; second-level separator we may have to precede the
&gt; "?" with
&gt; a "*".
&gt;
&gt; Combining separation and decoration is usually
&gt; considered
&gt; a visual simplification.  It has insignificant
&gt; development
&gt; and processing cost, but cuts the number of
&gt; characters
&gt; needed to communicate the same thing - in half.
&gt;
&gt; =Loren
&gt;
&gt; -----Original Message-----
&gt; From: Drummond Reed
&gt; [mailto:drummond.reed@cordance.net]
&gt; Sent: Wednesday, July 07, 2004 5:55 PM
&gt; To: Dave McAlpin; Wachob, Gabe; Loren West;
&gt; xri@lists.oasis-open.org
&gt; Subject: RE: [xri] Issue 1: Clarifying *
Semantics
&gt;
&gt;
&gt; First, there is a difference of opinion that "the
&gt; difference between the two options we are
discussing
&gt; is negligable" when it comes to the simplicity of
&gt; XRI
&gt; parsing. I invite other implementers to comment
on
&gt; the
&gt; simplicity of parsing two vs. three XRI separator
&gt; characters.
&gt;
&gt; On the second point, it is absolutely
unacceptable
&gt; to
&gt; require all human-friendly, reassignable XRIs to
&gt; include the star character. That would directly
&gt; conflict with the requirement of human-friendly,
&gt; reassignable XRIs being as simple and easy to
&gt; remember
&gt; as possible.
&gt;
&gt; =Drummond
&gt;
&gt;
&gt; To unsubscribe from this mailing list (and be
&gt; removed from the roster of the OASIS TC), go to
&gt;
http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php
.
&gt;



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]