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 /:123/, :123 is a segment - rule 1. The segment is composed on one subsegment, 123 - rule 3.


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Fri 7/9/2004 1:08 AM
To: Dave McAlpin; xri@lists.oasis-open.org
Subject: RE: [xri] Issue 1: Clarifying * Semantics

It seems to me that saying "preceed" blurs the distinction between a delimiter
and decorator. Delimiters delimit segments or subsegments. Decorators only
prefix segments/subsegments. If stars and colons can be both delimiters and
decorators, you end out with funny exceptions.

For example, if you apply your ruleset to "/:123/", is ":123" a segment or a
subsegment? If its a segment, you break rule 3. If its a subsegment, you either
break rule 1, because it's not a segment, or you have to posit a implicit null
subsegment between the slash and the colon.

A clean division between delimiters and decorators avoids all that.

=Drummond


--- Dave McAlpin <Dave.McAlpin@epok.net> wrote:
&gt; I think you made that a little more difficult than it had to be. Couldn't
you
&gt; say something like.
&gt; 
&gt; 1) Slashes delimit segments
&gt; 2) Stars precede reassignable sub-segments
&gt; 3) Colons precede persistent sub-segments.
&gt; 4) Stars may be omitted before the first subsegment in a segment and
before a
&gt; relative cross-reference.
&gt;
&gt; ________________________________
&gt;
&gt; From: Drummond Reed [mailto:drummond.reed@cordance.net]
&gt; Sent: Fri 7/9/2004 12:07 AM
&gt; To: xri@lists.oasis-open.org
&gt; Subject: RE: [xri] Issue 1: Clarifying * Semantics
&gt;
&gt;
&gt;
&gt; Dave and I talked late today about this issue (he's
&gt; headed out of town tomorrow), and I think our
&gt; conversation helped me better understand the crux of
&gt; the issues here. In this message I'll try to:
&gt;
&gt; a) summarize that understanding first,
&gt; b) clear up one misconception,
&gt; c) further clarify one point being discussed, and
&gt; d) share a long-term perspective that I have been
&gt; applying to this issue.
&gt;
&gt; SUMMARIZING THE ARGUMENTS
&gt;
&gt; The case for "dual subsegment delimiters" (star and
&gt; colon both) seems to rest primarily on two points:
&gt;
&gt; 1) Backwards compatability with XRI 1.0.
&gt;
&gt; 2) Compactness of consecutive persistent XRI
&gt; subsegments because only colon is needed to both
&gt; delimit and "decorate" them.
&gt;
&gt; The case for "one subsegment delimiter and one
&gt; persistence decorator" also seems to rest primarily on
&gt; two points:
&gt;
&gt; 1) Simplified parsing and interpretation rules (for
&gt; both machines and humans)
&gt;
&gt; 2) Freeing up colon to be used by producer-specific
&gt; algorithms (see new subthread I just posted).
&gt;
&gt; CLEARING UP ONE MISCONCEPTION
&gt;
&gt; In messages earlier today there were references to my
&gt; early proposal to do away with the concept of
&gt; subsegment altogether by putting star on an equal
&gt; footing with slash. Although I still believe in the
&gt; underlying motivations for this proposal, I was
&gt; convinced by the subsequent discussion that it was
&gt; better to keep the current "two-level" structure of
&gt; XRIs, i.e., major segments (slash delimited) and minor
&gt; subsegments. The reason was backwards-compatability
&gt; with URIs, which depends heavily on having only a
&gt; single major segment delimiter (slash).
&gt;
&gt; However the main motivation behind this proposal was
&gt; and still is simplification of XRI syntax. The simpler
&gt; the better (as long as it is still sufficiently
&gt; expressive). To that end...
&gt;
&gt; FURTHER CLARIFYING THE SIMPLIFIED
&gt; PARSING/INTERPRETATION RULES
&gt;
&gt; Since one of the main motivations for the single
&gt; subsegment delimiter approach is the simplified
&gt; parsing and interpretation rules for both machines and
&gt; humans, I thought it would be helpful to actually list
&gt; the rules involved. My inspiration for this was my
&gt; experience updating the proposed XDI addressing rules
&gt; to reflect single subsegment delimiter syntax. I found
&gt; myself very surprised at how much simpler things got.
&gt;
&gt; So, herewith my summary of the rules involved:
&gt;
&gt; RULES FOR DUAL SUBSEGMENT DELIMITERS:
&gt; Rule 1) Slashes delimit segments
&gt; Rule 2) Stars or colons delimit subsegments UNLESS the
&gt; star or colon immediately follows a slash, GCS
&gt; character, or opening parentheses, in which case the
&gt; star or colon is only a reassignable or persistent
&gt; decorator
&gt; Rule 3) A segment or subsegment is persistent if it is
&gt; preceeded by a colon used EITHER as a delimiter or a
&gt; decorator
&gt; Rule 4) A segment or subsegment that is preceeded by a
&gt; star that is NOT used as a delimiter is equivalent to
&gt; the same segment or subsegment without the star
&gt;
&gt; RULES FOR A SINGLE SUBSEGMENT DELIMITER:
&gt; Rule 1) Slashes delimits segments
&gt; Rule 2) Stars delimits subsegments
&gt; Rule 3) Colon decorates (prefixes) any persistent
&gt; segment or subsegment.
&gt;
&gt; I don't know about anyone else, but I find the
&gt; differences in these two rulesets striking. I think
&gt; the reason is that the whole concept of a
&gt; "reassignable decorator" just goes away. It's not
&gt; needed anymore. Delimiters are delimiters, decorators
&gt; are decorators, and only one decorator is needed -
&gt; colon.
&gt;
&gt; TAKING THE LONG-TERM PERSPECTIVE
&gt;
&gt; In several other recent conversations I have shared
&gt; the perspective I've been applying to this issue,
&gt; which is: "What is best thing for XRIs in the long
&gt; run?" Yes, the issue of backwards compatability with
&gt; 1.0 is very important. But realistically, the XRIs
&gt; that exist today are probably less than .001% of the
&gt; XRIs that will exist 10 years from now. We are at the
&gt; very earliest stages of real-world deployment.
&gt;
&gt; Thus, as we have agreed several times, 1.1 is our
&gt; single best opportunity to make any changes to the
&gt; syntax that make it as clean and simple as possible
&gt; for the 99.99% of all XRIs to come.
&gt;
&gt; This is the reason I am a proponent of the single
&gt; subsegment delimiter proposal. It is in my view a
&gt; fairly dramatic improvement in simplicity. When paired
&gt; with the advantage that it frees up colon to be used
&gt; (along with dot) in producer-specific algorithms for
&gt; subsegment composition - and that this cushions the
&gt; problems with backwards compatability - I believe the
&gt; benefits well outweigh the costs.
&gt;
&gt; =Drummond
&gt;
&gt; To unsubscribe from this mailing list (and be removed from the roster of
the
&gt; OASIS TC), go to
&gt;
http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php.
&gt;
&gt;
&gt;
&gt;



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