OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Issue 1: Clarifying * Semantics


Title: Re: [xri] Issue 1: Clarifying * Semantics
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


From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
Sent: Fri 7/9/2004 9:10 AM
To: Fen Labalme; Loren West
Cc: xri@lists.oasis-open.org
Subject: RE: [xri] Issue 1: Clarifying * Semantics

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]