I should point out that rule
one ("slashes delimit segments") isn't very rigorous in either ruleset since
question mark and pound sign also delimit segments. Also, rule three in the
proposal can be simplified to "Colon decorates (prefixes) any persistent
subsegment" - there's no reason to invent the concept of a "persistent
segment" that consists of one persistent subsegment.
The proposal _does_ remove an ambiguity
from one unusual case. In xri:@example*(this:that), it's not clear whether
this:that is a relative cross-reference or an absolute URI in the "this" scheme.
Under the proposed rules, it would be clearer as xri:@example*(this*:that).
The first can be easily handled, however, using a greedy algorithm as described
in 2396.
Dave
Fen,
One good thing that's come out of this
dicussion is a succinct expression of the rules involving star and colon.
For me, at least, it's now much easier to explain and understand the rules.
Here's the current and proposed rules for star and colon.
Current:
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
Proposed:
1) Slashes delimits segments
2) Stars
delimits subsegments
3) Colon decorates (prefixes) any persistent segment or
subsegment.
4) Undecorated sub-segments are considered
reassignable.
Note that both rulesets take advantage of
the fact that a GCS character is not technically a sub-segment. If we want to be
explicit about GCS characters, we'd need to add a rule to both that said
something like, "Stars may be omitted between a GCS character and the
sub-segment that follows".
To me, both seem equally
understandable. This isn't surprising because, as Drummond has pointed out
before, the proposal requires very few changes to the ABNF. That's another
indication, by the way, that the complexity in parsing isn't substantially
affected.
There may be good reasons to consider the
proposed change, but I really don't think simplification is one of
them.
Dave
From: Fen Labalme
[mailto:fen@idcommons.org]
Sent: Fri 7/9/2004 3:16 AM
To:
Loren West
Cc: xri@lists.oasis-open.org
Subject: Re: [xri]
Issue 1: Clarifying * Semantics
Loren -
While you are correct that it's all SMOP (a Small
Matter of Programming) and
the differences we're talking about are somewhat
minimal in regards to the
complexity of the parser, the one less rule makes
it quite a bit easier for
the programmer *writing* the parser to understand
things, and thus decreases
effort and mistakes.
It also makes it more
likely that a human who happens to see a (HFI-based) XRI
string has a chance
to understand what it means.
This is important in the world of Identity
Commons where we expect users to
see XRIs and, just like URLs, have some sort
of grasp as to what they convey.
Fen
Loren West wrote:
>
I can easily say the parsing rules are equally simple, because as
>
someone who knows the complexity of writing a parser, I know
> that the
hard part isn't in the differences we're talking about
> on this
thread.
>
> =Loren
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.