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