[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Issue 1: Clarifying * Semantics
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]