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


Drummond Reed writes:
> 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.
*****
I agree that while this is important, if there's 
something that a super-majority of the group feels
is much better (like the "." vs. "*" issue), now
is the right time to do it.

Not only is there not a super-majority, as you can
see from the volumes of mails on this topic, it's
become nearly impossible to declare one way better
than the other.

Compare this with the "." vs. "*" issue, and other
SAML issues that justified making the syntax
incompatible.  My guess (and hope) was that the
incompatibilities that the SAML group introduced
were well known problems with prior versions vs.
differing opinions of "better" that happened to
pass a simple majority vote.

> 2) Compactness of consecutive persistent XRI
> subsegments because only colon is needed to both
> delimit and "decorate" them.
******
Yes, making the XRI simpler.

> 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)
******
See separate email thread on this.  The parsing and
interpretation rules are equally simple.  There
are differences, and it's just as easy to make 
declarations of simplicity with either syntax.

> 2) Freeing up colon to be used by producer-specific
> algorithms (see new subthread I just posted).
******
Dave clarified the flaw in this.

> ...
> 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
******
See separate email thread.  This was made to seem more
difficult than it really is.  Hopefully the subsequent
clarifications show that from a parser to a human being,
these rules are equally simple.

> 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.
******
Well, at least we can agree on the costs.  I sincerely
believe the existing syntax is easier to read and
just as easy to parse, and for the same reasons you
state above, believe staying with the 1.0 syntax is
the best long term direction for XRI.

=Loren



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