[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Issue 1: Clarifying * Semantics
I can easily say the parsing rules are equally simple, because as someone who knows the complexity of writing a parser, I know that the hard part isn't in the differences we're talking about on this thread. =Loren -----Original Message----- From: Drummond Reed [mailto:drummond.reed@cordance.net] Sent: Thursday, July 08, 2004 11:12 PM To: Loren West; xri@lists.oasis-open.org Subject: RE: [xri] Issue 1: Clarifying * Semantics How can you say, "the parsing rules are equally simple"? Any way you do it, you end out with at least one less rule with a single subsegment delimiter. And you get a clean separation of delimiters and decorators. =Drummond --- Loren West <loren.west@epok.net> wrote: > If you don't like Dave's use of the word preceed, and want to consider > stars and colons as ALWAYS both sub-segment separators AND decorators, > then the rules look like this: > > 1) Slashes delimit segments > 2) Stars delimit reassignable sub-segments > 3) Colons delimit persistent sub-segments > 4) Stars may be omitted before the first subsegment in a segment > > -and- with both proposals, when writing a parser you have to specify > what to do with null sub-segments (is it an error? if not, what do > you do?). So, the existing syntax gets: > > 5) Null sub-segments can be disregarded > > That handles the /:123/ issue where there are two sub-segments, > one null and one persistent. > > And it's unclear with the new proposal if the same rule exists, > or an equally complex rule exists: > > 5) Null sub-segments indicate an XRI error condition > > We're not talking about significant differences in complexity > of parser writing. You have to handle a null sub-segment one > way or the other. Throwing it away is just as simple (simpler?) > than dealing with it as an error condition. > > I still maintain the existing syntax simpler than the proposed > syntax because the parsing rules are equally simple, HFI's are > exactly equivalent, and MFI's are simpler without multiple > characters before each sub-segment. > > =Loren > > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Thursday, July 08, 2004 10:08 PM > 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 > === message truncated === 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]