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