RE: [xri] * and / discussion

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

Gabe, I agree with you that it would be good not to run "against the grain"
with regards to '/'. The ubiquitous support for hierarchy in RFC2396 is a
good reason to do that.

You go on to say, "That alone is a reason not to treat '/' as some random
character, or even as an equivalent character to '*'."

I agree with the first half of that statement, but I question the second
half. I believe we can preserve all the meaning that 2396 gives to slash
without diluting any of the meaning that XRI 1.x would give to star. As
Victor points out, giving peer links a clear syntactic expression in XRIs
could emerge (right along with cross-references, I'd argue) as the most
groundbreaking feature of XRI syntax.

I also believe this can be accomplished, if necessary, by still giving slash
segments "first precedence" as they have in 2396. But if we do that, star
segments should have second precedence, such as shown in the BNF at
http://xrixdi.idcommons.net/moin.cgi/ProposedXriSyntaxRevision#head-9def29be
b72d5abb3941723f3492e6c9c58fa03c. 

Let me illustrate this syntax with the following XRIs. The first two are
equivalent, with the only difference being that one uses e-names and one
e-numbers:

@ID.Commons*Mary.Smith/(+email)/(+work)/($v3)
@:1001*:398587/(+:14)/(+:32)/($:v3)

You can read either of these two XRIs for slash segments or star segments.
For slash segments, all 2396 rules apply. The part before the first slash is
the XRI authority segment, and delegation between XRI identifier authorities
is handled with star segments (just like dot segments in XRI 1.0). E-numbers
are signified by a colon prefixing any segment value.

But you can also read these XRIs for the star segments. Both of them have
one star segment following the first star. All that star segment tells you
is that you are switching from one hierarchy (defined by @ID.Commons) to
another one (defined by the resource that @ID.Commons knows as "Mary.Smith")

Here's another one:

=Mary.Smith/(@ID.Commons)*(/($contract)/(+employee)/($v2))*
	(/(+phone)/(+home)/($v3))

This XRI has two star segments, both after the first slash. Again, the only
thing you can read into these at the XRI syntax level is that when reach a
star, you are switching from one hierarchy (e.g.,
"=Mary.Smith/(@ID.Commons)") to another (e.g.,
"/($contract)/(+employee)/($v2)").

Conclusion: star syntax need not conflict with slash syntax. If the
conclusion of the TC is that slash segments should still have their same
hierarchical meaning as in 2396 (where the path component of 2396bisv6 is
called the "hier-part"), then we can retain that. From this perspective,
star segments will simply add another optional level of syntactic expression
to those XRI authors and applications that want to use them.

=Drummond 



-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Monday, June 14, 2004 4:17 PM
To: Peter C Davis; xri@lists.oasis-open.org
Subject: RE: [xri] * and / discussion

Peter-
	I think you are responding to my "why define anything to the right
of the first slash" question. I understand your response, and appreciate the
approach.
	However, RFC2396 is very explicit about the concept of path
separation. So while I would argue that we don't have to define the
semantics of path separation, its a useful concept for building structure in
an XRI beyond just seperating the ID Authority from the local party. 
	I guess at the end of the day, I don't see why we are retreating on
treating '/' specially. RFC2396 treats '/' specially without defining how
'/' is interpreted from scheme to scheme except by defining a (very
imporant) de-relativizing algorithm. That alone is a reason not to treat '/'
as some random character, or even as an equivalent character to '*'. I
intend to use XRIs where URIs are specified, so I expect a generic URI
parser to have some reasonable chance of success in dealing with them. Thus,
'/' should be treated by us in the same way that it is treated in RFC 2396
(and -bis). 

	-Gabe
 
__________________________________________________ 
gwachob@visa.com
Chief Systems Architect
Technology Strategies and Standards
Visa International 
Phone: +1.650.432.3696   Fax: +1.650.554.6817


> -----Original Message-----
> From: Peter C Davis [mailto:peter.davis@neustar.biz]
> Sent: Monday, June 14, 2004 3:46 PM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] * and / discussion
> 
> 
> I personally do not see the need for explicit delagation characters
> within the local-part of the address structure.  consider the 
> case today
> for http URIs:
> 
> http://www.example.com/~foo/
> 
> The DNS describes nicely the delegation of the 'authority-part' of the
> address, and host-level file systems delegate further, based on local
> policy.  Why should XRI's be any different.  I cannot see a 
> reason that
> an application consuming this resource (ultimately index.html... but
> thats local policy too ;-)  need to understand that the '~' here meant
> delegation.
> 
> If local access points services an XRI choose to delegate at the '/',
> then so be it.  If clear delegation semantics are needed by a 
> particular
> usecase, cannot they simply supply cross-references instead?
> 
> Or then again, perhaps i did not eat enough wheaties this morning.
> 
> ---- peterd
> 
> 
> On Mon, 2004-06-14 at 16:47, Wachob, Gabe wrote:
> > Drummond-
> > 	Comments inline..
> > 
> > > 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.
> > 
> > Two responses:
> > 
> > 1) I don't see resolution as "an application". Its 
> something we carefully built our identifiers around and, 
> quite frankly, are essential to the value of XRIs. Resolution 
> gets special consideration in terms of what you do with XRIs. 
> I believe its absolutely essential that resolution 
> infrastructure be widely deployed and if we are talking about 
> resolution as merely "an application", it takes away from the 
> perceived value of XRI
> > 
> > 2) I think the less structure we define for XRIs, the 
> harder it is for folks to build applications of XRIs since 
> they're going to have to do more of the parsing in the 
> application, and less can be done at the "library" layer. 
> Chunking, as I'm calling it, is a *feature* of XRIs that I 
> value. And I assumed that XRI libraries would naturally 
> expose the structure of XRIs in this way. If you remove the 
> chunking (ie nested chunking), and I have to recreate it in 
> an application, then it seems to me that XRIs become somewhat 
> less valuable. I could do that (chunking by 
> application-specific convention) just as easily with HTTP URLs. 
> > 
> > > 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.
> > 
> > Yes, but I might do it differnetly than the next 
> application, and that means writing code specifically for my 
> application. This takes away from the value of XRIs. 
> > 
> > Taking your logic to its end, why do we specify *any* 
> structure to the right of the first slash? 
> > 
> > 	-Gabe
> > 
> > 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.
> 
> 
> 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.
> 

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
.