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
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]