RE: [xri] Issue 1: Clarifying * Semantics

["Loren West" <loren.west@epok.net>]

Drummond,

My responses are inline, but you will see a common
thread in each of them.  To summarize, from a development
perspective, these perceived simplifications aren't
significant enough to warrant a change to the specification.

I understand how you see a single separator as a simplification,
and hope you can understand how I see ":" as a simplification
over "*:".  They're both "simpler", but one doesn't require
a change to the specification.

=Loren

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Wednesday, July 07, 2004 5:12 PM
> To: Wachob, Gabe; Loren West; xri@lists.oasis-open.org
> Subject: RE: [xri] Issue 1: Clarifying * Semantics
> 
> As one of the proponents of this proposal (who is
> finally getting caught up with his vacation email),
> I'll accept Gabe's invitation to speak up about it.
> 
> I don't believe this change is "aesthetic" (I agree an
> aesthetic change could be argued ad infinitum either
> way.) It is functionally motivated by the following
> reasons:
> 
> 1) Having a single second-level separator character
> simplifies the parsing and interpretation of XRIs (it
> reduces the number of separator chars from 3 to 2).
*****
[Loren] - Yes, but it doubles the number of characters
needed to communicate what ":" currently communicates.
And I still haven't heard how this significantly
affects how the parser is written.

> 2) As Gabe's summary points out, it eliminates any
> special rules about "implied" reassignable decorators
> (currently leading dots) in segments. Instead, the
> rules would now be crystal clear: slashes and stars
> are separators; the presence of a colon after either
> one (or a GCS char) indicates the segment is a
> persistent identifier; the absence of a colon means
> the segment is a reassignable identifier.
*****
[Loren] - Agreed.  This is somewhat simpler.  But from
a development perspective, it's not significant.  If
something is implied, the code just changes a bit to
understand that condition.

> 3) The elimination of such special rules simplifies
> XRI normalization and comparison.
*****
[Loren] - Same as above.  It takes less time to write
the code that understands those situations than it has
to write this response.

> 4) This overall simplification of XRI construction
> also simplifies the development of XRI applications
> such as XDI.
******
[Loren] - Can you describe how the format of the identifier
simplifies the development of XRI applications such
as XDI?  As an actual developer of XRI applications, and a
prospective developer of XDI applications, I can't see
how this affects development one way or the other.

> =Drummond