[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]