[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Issue 1: Clarifying * Semantics
A segment is a subsegment? How can it be a subsegment if there's
no other
subsegment? Or is there another null subsegment before the
colon?
If I wrote "//" in URI syntax, it would be very clear that this
was a null
segment. So is there a null segment between slash and colon in
"/:"?
My point is, the colon in "/:123" doesn't DELIMIT anything. And yet
we've
defined colon as a DELIMITER.
Stop defining colon as a delimiter
and define it only as a decorator and the
whole problem just
vanishes.
=Drummond
--- Dave McAlpin
<Dave.McAlpin@epok.net> wrote:
> In /:123/, :123 is a segment -
rule 1. The segment is composed on one
> subsegment, 123 - rule
3.
>
>
________________________________
>
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
>
Sent: Fri 7/9/2004 1:08 AM
> 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
> &gt;
> &gt; To unsubscribe from
this mailing list (and be removed from the
roster of
>
the
> &gt; OASIS TC), go to
>
&gt;
>
http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php.
>
&gt;
> &gt;
> &gt;
>
&gt;
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]