RE: [xri] Issue 1: Clarifying * Semantics

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:
> 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
.
>
>
>
>

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
.

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.

xri message