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