FW: [xri] Another perspective on GCS star issue

["Lindelsee, Mike " <mlindels@visa.com>]

Comments inline.

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Wednesday, August 25, 2004 10:22 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] Another perspective on GCS star issue
> 
> 
> Further reflection on the "star optional after a GCS 
> character" issue on the
> XRI Editor's SC call yesterday has produced two additional 
> perspectives I
> believe may be helpful. Since I'll be on the road for tomorrow's XRI
> Editor's SC call, I'll post these thoughts here so folks can 
> review them
> before the call.
> 
> The first perspective is based on overall treatment of null 
> segments in XRI
> syntax; the second based on overall treatment of first subsegments.
> 
> OVERALL TREATMENT OF NULL SUBSEGMENTS
> 
> So far in XRI 1.1 we've made three decisions relative to null 
> subsegments:
> 
> 1) Generic XRI syntax should allow null subsegments, for the 
> same reasons
> that RFC2396bis does (and because they are required by at 
> least one XRI
> application, XDI.)
> 

Agreed, with the caveat of #2 that follows.

> 2) The XRI authority portion of an XRI, where we have an 
> interest in tighter
> syntactic rules in order to support reliable XRI resolution, 
> should as a
> rule not allow null subsegments.
> 

Yes, agreed.

> 3) The one exception is null subsegments after a GCS 
> character in order to
> allow a persistent subsegment delimiter ("!") to follow a GCS 
> character.
> 

Here, I have a different interpretation.  I don't believe that we are allowing a null subsegment in this position in the XRI.  We are, instead, allowing the sub-segment delimiter to be left out.  While we don't call out the GCS characters as sub-segments in the ABNF, they behave exactly as sub-segments do.  That is, to identify a single authority that is the context for resolving the authority described by the following sub-segment.  Since the GCS characters are disallowed (unless escaped or in a cross reference) in the following subsegments, the delimiter following a GCS character is redundant since it is clear that a new sub-segment follows.  It still bothers me to say that one type of delimiter follows a GCS character and another cannot.  I still far prefer to allow (but not require) both delimiters to follow the GCS character with the understanding that a missing delimiter indicates a reassignable sub-segment.

> It is #3 that leads to the issue we are discussing, namely: 
> should we also
> allow a * null subsegment after a GCS character, and if so, 
> what does it
> mean?

See above -- I don't believe that this is a reasonable interpretation.

> 
> The perspective that comes from looking at the overall issue of null
> subsegment significance in XRIs is this: from the standpoint 
> of generic XRI
> syntax, a null subsegment MUST be treated as significant in 
> an XRI path,
> because applications like XDI are counting on this behavior. 
> For example,
> the following two XRIs MUST NOT be considered equivalent:
> 
> @foo/bar
> @foo/*bar
> 

I don't believe that this argument is relevant to the points above.  Above we are talking specifically about the possibilty of optionally leaving off the reassignable subsegment delimiter only after a GCS character.

I believe that what you are arguing for here is not really about allowing null subsegments, but having a richer set of application-specific delimiters.  While I'm all for supporting that, I don't think we need to build direct support for application-specific delimiters (in the local path part of an XRI) into the XRI syntax.  Perhaps we should loosen our definition of the local part part of the XRI to somthing as simple as:


   local-path   =  * ( pchar / "*" / "!" / etc. )

This would allow the most flexiblity in terms of applications being able to define their own syntax/sematics on top of XRIs.


> In XDI, these would address completely different resources. Thus the
> significance of the star as a null subsegment delimiter is 
> critical to XDI
> addressing.
> 
> It would be consistent with this rule to say the presence of a null
> subsegment in an XRI authority MUST also be treated as 
> significant. This is
> also consistent with rule #2 above about why we do not allow null
> subsegments in an XRI (because if they were present they would be
> significant.)
> 

Again, I think we are not talking about null sub-segments in the authority part -- definitely in the local path part, but we have explicitly disallowed null sub-segments in the authority section.  Your reasoning sounds valid, but it is based on a flawed premise, so I believe that you are heading towards a flawed conclusion.


> The logical conclusion is that if we allow null subsegments 
> after a GCS
> character before a * delimiter, the null subsegment MUST be considered
> significant. That would mean that the following would not be 
> equivalent:
> 
> @foo
> @*foo
> 
> However we were in a agreement on yesterday's call that if @*foo were
> allowed, it should be equivalent to @foo.
> 

As I said on the call yesterday, the simplest way to solve the problem (though not necessarily the most human-friendly way) would be to always require the sub-segment delimiters after a GCS char.  I.e.,

  xri:@!foo
  xri:@*foo

The ABNF is simplified, processing and resolution rules are simplified, and there is no confusion for people looking at the XRI.  Your reasoning and proposed solutions seem to make things far more complicated.  To make the syntax somewhat more human friendly, I don't see a problem with complicating the rules a bit and allowing default behavior by allowing the "*" to be optional. 


> OVERALL TREATMENT OF FIRST SUBSEGMENTS
> 
> A second perspective on this issue comes from the overall XRI 
> treatment of
> first subsegments. In XRI 1.0, we defined that the first 
> subsegment in a
> segment was reassignable by default if it was not preceeded 
> by a persistent
> subsegment delimiter, because that's the way URIs and file 
> paths and many
> other path-based addressing systems already worked. So in 
> "/foo/bar", "foo"
> and "bar" were both reassignable by definition.
> 
> We applied the same rule to GCS characters for the same 
> reason: it made them
> as simple and human-friendly as possible, and the behavior 
> was consistent
> with "//" in URI authorities.
> 

Actually, the GCS characters aren't equivalent in behavior to "//" in URIs.  The "//" is a delimiter that indicates that an authority follows.  The GCS characters are authorities in themselves.  I believe that XRI 1.0 didn't have an analog for "//" wrt XRI authorities.  The GCS characters behave much more like the implicit "." in DNS names.  The reason we can't make them implicit is that we have more than one.

> Conclusion: since the rule for ALL segments in an XRI is that 
> the first
> subsegment is reassignable unless preceeded by a persistent subsegment
> delimiter, there is no need to add a * to indicate reassignability.
> 

Agreed.  My position all along has been that this is the case and that we shouldn't complicate the rules by saying that the reassignable delimiter should *never* be used in this position.


> CONCLUSION
> 
> From these two larger perspectives, it seems to me that we 
> only have two
> choices wrt the issue of * null subsegments after a GCS character:
> 

Again, that wouldn't be a null sub-segment.

> 1) Disallow them, OR
> 2) If a * null subsegment after a GCS character is allowed, 
> it MUST NOT be
> equivalent to the same string without the *.
> 

I'm not convinced that these are the *only* options.  For instance, what is the problem with allowing the reassignable delimiter after a GCS character and allowing a default of not placing it there.  That way, xri:@foo and xri:@*foo are equivalent.  I would argue that this is neither complicated nor hard to understand.

Another option is to always require the sub-segment delimiters after a GCS character.  Also, not particularly complicated and arguably the easist for people to understand and interpret.


> Since the second would be very confusing, I'd recommend 
> option 1. I believe
> this is consistent with treating GCS characters as the XRI 
> equivalent of
> "//".
> 

Again, I think that this interpretation of GCS characters doesn't' work.

> A second recommendation, which I believe would solve the 
> problem wrt to XRI
> resolution rules, is to define a single rule for the value passed by a
> resolver to an XRI authority: it should be ***the subsegment 
> value plus any
> preceeding subsegment delimiters***.
> 
> This would eliminate any inconsistency between default reassignable
> subsegments and explicit persistent subsegments.
> 
> Examples:
> 
> @foo			To the "@" authority, pass "foo"
> @!foo			To the "@" authority, pass "!foo"

Yes, with the caveat that I belive that we should follow XRI 1.0 precedent and pass "*foo" in the first case.

> @foo*bar		To the "@foo" authority, pass "*bar"
> @foo!bar		To the "@foo" authority, pass "!bar"

I'm not quite following here.  Wouldn't you follow the same process you did in the previous 2 examples?  E.g., pass "foo" to the @ authority (perferably, "*foo"), and pass "*bar" to the foo authority?


> 
> It's also consistent with the proposed XDI addressing rules, 
> which operate
> the same way only internal to XDI documents (i.e., they take 
> over starting
> with the XRI path.) For example:
> 
> /foo			From the XDI document root node, resolve "foo"
> /!foo			From the XDI document root node, resolve "!foo"
> /*foo			From the XDI document root node, resolve "*foo"
> /*!foo		From the XDI document root node, resolve "*!foo"
> /foo/bar		From the "/foo" node, resolve "bar"
> /foo/!bar		From the "/foo" node, resolve "!bar"
> /foo/*bar		From the "/foo" node, resolve "*bar"
> /foo/*!bar		From the "/foo" node, resolve "*!bar"
> 


Again, when it comes to the local path part of the XRI, I think that the XRI spec should be a flexible and accomodating as possible.  Perhaps we should seriously consider reducing the amount of syntax we specify in the local path and leave it for applications of XRI, such as XDI, to define their own syntax and semantics.

Fundamentally, I am arguing for a simple and regular approach to both the ABNF and resolution rules.  The proposals discussed on the editor's call and in this email are attempting to make the grammar more irregular and resolution of XRI have more special cases.  I think that doing so would be a mistake.  If XDI needs more flexibility in the local path than XRI currently allows, I am happy to consider loosening the syntax XRI defines in the local path, but we should do is in a simple fashion, and not build in complicated syntax or semantics that may or may not be appropriate for other application that will use XRI.

Mike