* and / discussion

["Drummond Reed" <drummond.reed@cordance.net>]

[Note: I changed the subject line because this thread is much more focused.
=Drummond]

Gabe, I agree that it's syntactic rules we're talking about, which is why I
put "semantics" in quotes.

In terms of "chunking", or more technically, "segmentation", it seems like
there are two approaches we can take.

1) Keep the current 1.0 segmentation hierarchy, i.e., divide XRIs into slash
segments first, then divide slash segments into star subsegments (or star
and colon subsegments).

2) Or, as I'm arguing, make it even simpler by just defining two syntactic
segment types - slash segments and star segments - and then let XRI
applications use them as they wish. In this approach, XRI resolution would
be one such application, and that application would define star segments
before the first slash to be authority delegation.

I don't understand what you mean by the following:

"But I *still* want the ability to chunk things together beyond the
authority - if we say / and * are peers, then the only namespace-independent
chunking syntax we have is () -- ie cross references..."

If you want segmentation ability beyond the XRI authority segment, as the
XRI author you control this completely. You can use slash segments exactly
the way you say you'd like to, and treat star segments as subsegments inside
slash segments. Another authority could do exactly the opposite with their
XRI paths. Both would be syntactically legal and interoperable.

The point I'm arguing for is doing the simplest and most general thing. If
we just define the two segment types, then applications and XRI authors can
choose either model, rather than being constrained to the
slash-segment-and-dot/colon-subsegment model we have in XRI 1.0.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Monday, June 14, 2004 12:55 PM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] A different perspective on * and / (long)

Drummond-
	Comments inline.

> Gabe, you're correct that, for the XRI resolution, we still 
> need to "add
> semantics" to the two segment types, i.e. to define that within an XRI
> authority segment, one of the two delimiters (slash) is the 
> delimiter that
> marks the end of the authority segment, and the other (star) 
> is used for
> subdelimiting authorities within the XRI authority segment.

But its more than "adding semantics" - we have to treat the whole set of
stuff before the first slash as a unit, and thats why / and * would be
different. * is not required to have any such chunking behavior, whereas /
does. This is irrespective of "semantics" - its a syntax issue. 

Now, I'm having a hard time parsing the BNF (because I'd have to spend more
time with it) - maybe in fact, you are, for the authority, defining the
syntax differently so that, from a BNF point of view, / is treated
differently for the identifier authority part. Fine.

But I *still* want the ability to chunk things together beyond the authority
- if we say / and * are peers, then the only namespace-independent chunking
syntax we have is () -- ie cross references... is that acceptable? 

For example, i'd no longer be able to reliably break up the following
identifier:

@GabeWachob/address*home/city

I'd have to use cross references to ensure its "broken up" the right way:
@GabeWachob/(+address*home)/(+city)   --or--
@GabeWachob/(+address*home)*(+city)

At this point, if we are going to make * and / semantically equivalent
(absent some specific application), whats the point of having * at all? Why
not just say '/' is the only XRI-defined delimiter outside the identifier
authority? What does * add outside the identifier authority? 

	-Gabe