[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
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]