OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xri] RE: Simplified 1.1 path syntax (was Another perspective on GCS star issue)

Mike, I agree with the generalized approach being discussed, since obviously
I'd like to see the flexibility for both XDI and other XRI applications to
define their own semantics in the local part.

And yours and Gabe's proposal accommodated the concept of xrefs in the local
part, making them part of the "universal" structure of XRIs (which again I
think is well worth it, just as the universal hierarchical structure of URIs
has proved very valuable for many applications.)

While multi-axis addressing may or may not be a "universal" concept needed
by other applications, it certainly seems to me that persistent identifiers
is. Integrated support for both persistent and reassignable segments has
been item #1 in the XRI charter from day 1. (Again, to reinforce our earlier
discussions about this, it's not because persistence can be enforced
technically, but because support at the technical syntax level is a
requirement for persistence to be able to be supported at the operational
level in those identifier communities who do choose to support it.)

Thus it would be a shame to lose "universal" support for persistence at all
levels of an XRI by generalizing the local part too far. 

Have you and Gabe discussed any ideas for how we could explicitly support
the concept of a persistent segment or subsegment in a simplified local
part, rather than making it something entirely application dependent? Is
there an easy way we could do it in a manner that's consistent with how we
propose to do it in the XRI authority part?

I'll think about this too.


-----Original Message-----
From: Lindelsee, Mike [mailto:mlindels@visa.com] 
Sent: Monday, August 30, 2004 5:02 PM
To: xri@lists.oasis-open.org
Subject: RE: [xri] RE: Simplified 1.1 path syntax (was Another perspective
on GCS star issue)

I understand what you want wrt "multiple axis addressing," but feel quite
strongly that this is complexity that is completely out of scope for XRI.
If it is necessary for XDI, then we need to be able to accomodate it in the
XRI syntax (hence the need for less specificity in the local part
productions), but we shouldn't define syntax that XRI *doesn't* use.  This
situation is exactly the reason that 2396bis introduces sub-delims --
reserved characters that can be used as delimiters by URI-producing
applications (XRI-producing applications such as XDI, in our case).  

If we want to call out "*" and "!" as "xri-sub-delims," I'm ok with that (as
I indicated in my previous email).  We define semantics around those
characters and so I don't have a problem with defining their syntax.  I
would strongly recommend that we either (1) keep the local part production
as simple as possible with "/" being the only delimiter (to be clear, I
don't consider "(" or ")" to be either segment or sub-segment delimiters --
therefore xrefs can exist as part of a segment or sub-segment) we call out
in the production or (2) call out "*" and "!" as xri-sub-delims and have
them behave in exactly the same way that they do in the authority part.  In
both cases, XDI would be able to define the syntax and semantics of the
other characters in xri-sub-delims for use in "multiple axis addressing."
For example, you could potentially use any of "&", ":", ";", ",", and "'" as
other "multiple axis delimiters."


> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Monday, August 30, 2004 4:19 PM
> To: Lindelsee, Mike ; xri@lists.oasis-open.org
> Subject: RE: [xri] RE: Simplified 1.1 path syntax (was Another
> perspective on GCS star issue)
> Good points, Mike. I agree with your rationale.
> In the course of reviewing its requirements, what XDI really 
> discovered was
> its need for what XPath calls "multiple axis" addressing, 
> i.e., the ability
> to include an optional prefix of one or more characters 
> before an identifier
> that indicates which of several potential addressing axis the 
> identifier
> following the prefix is intended to address.
> Since the addition of persistent identifiers in XRI to the 
> current default
> of reassignable identifiers in URIs already introduces a 
> second "axis" of
> addressing -- and one that I think should continue to be a fundamental
> feature of XRIs -- what I'm wondering is whether in XRI 1.1 
> we should't be
> trying to evolve the XRI 1.0 concept of subsegments into the more
> generalized concept of axis prefixes.
> For example, a simple way to do this in the ABNF would be:
> xri = xri-auth [local-path] [query] [fragment] 
> local-part = "/" *( axis-delims / xref ) *lchar [local-part] 
> lchar = all legal XRI characters except /()?#
> Note that this would mean an xref can also be used as an axis 
> delimiter,
> which is a perfect use of xrefs.
> A slightly more elaborate form, which would fully support the XRI 1.0
> concept of subsegments, would be to make it recursive, i.e.:
> local-part = "/" * ( *( axis-delims / xref ) *lchar ) [local-part]
> From this perspective, you could look at subsegments within the XRI
> authority segment as a special case of this general 
> multi-axis addressing,
> where * is designated (in place of /, which can't be used in an XRI
> authority segment) as the reassignable axis, and ! as the 
> persistent axis.
> =Drummond 
> -----Original Message-----
> From: Lindelsee, Mike [mailto:mlindels@visa.com] 
> Sent: Monday, August 30, 2004 2:27 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] RE: Simplified 1.1 path syntax (was Another 
> perspective on
> GCS star issue)
> While this is a good point, Drummond, it seems to me that the 
> reason we are
> trying to relax the syntax of the local part of an XRI is allow the
> flexibility to support XDI.  If it were sufficient to have "!" as the
> persistant delimiter and "*" as the reassignable delimiter, I 
> would agree
> with you completely.  My understanding, though, is that XDI needs more
> flexibility to define additional delimiters reusing 
> combinations of "!" and
> "*".  My concern is that either XRI defines syntax and no 
> related semantics
> (in which case, why are we defining the syntax?) or we define 
> both syntax
> and semantics of local part sub-delimiters in the XRI spec 
> and XDI then
> changes those semantics.  To be concrete, in XRI terms, 
> "/*!foo" would be
> have a specific meaning.  It would literally be a null 
> reassignable segment
> followed by a persistant segment foo.  If XDI changes "*!" to 
> mean something
> else, then it breaks the meaning defined in XRI.
> My goal is to give applications that use XRI (such as XDI) 
> the flexibility
> to define what they need in the local part without having to redefine
> syntax/semantics already defined the XRI spec.
> I truly think that to allow the most flexiblity, XRI 1.1 
> should define only
> "/" as a segment delimiter in the local part and allow the "*" and "!"
> characters, just not assign any particular meaning to them -- 
> any meaning
> will be assigned by particular applications.  Since XDI would 
> be redefining
> the semantics of delimiters in the local part anyway, I don't 
> see it being
> much overhead to also have XDI be specific about the syntax 
> of the local
> part.
> As an alternative, XRI 1.1 could define syntax and semantics 
> for "*" and "!"
> as delimiters in the local part if XDI could use "*" and "!" in their
> XRI-defined way (i.e., no null sub-segments that would allow 
> "*!" etc.).
> XDI could then use *different* delimiters to express the 
> anything else that
> XDI needs to express.  The xri-sub-delims lists the other characters
> intended to be used this way.
> Mike
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Monday, August 30, 2004 1:57 PM
> > To: Lindelsee, Mike ; xri@lists.oasis-open.org
> > Subject: Simplified 1.1 path syntax (was Another perspective 
> > on GCS star
> > issue)
> > 
> > 
> > I too like the overall idea of leaving the 1.1 path as simple 
> > and flexible
> > as possible so that application developers can design what 
> meets their
> > needs.
> > 
> > However, just as URI choose to define one element of path 
> > syntax "universal"
> > enough to be of broad use to all application developers who need it
> > (hierarchy syntax), I believe XRI has at least two elements 
> > of path syntax
> > that also meet that requirement:
> > 
> > 1) Persistent identifier syntax
> > 2) Cross-reference syntax
> > 
> > As Dave McAlpin suggested on last Thursday's XRI Editor's SC 
> > call, we can
> > take the same approach wrt to these two features as 
> > RFC2396bis takes to
> > hierarchical slash syntax, which is to say that while 
> > applications are not
> > required to use these XRI features in the path section, the syntax
> > specifided for these features is reserved to this purpose and 
> > MUST NOT be
> > used for another purpose.
> > 
> > Anyone who doesn't agree with this approach, please post to 
> the list.
> > 
> > Otherwise, our action item for 1.1 is to:
> > 
> > 1) Propose a simplified path structure in the 1.1 ABNF that 
> > supports what is
> > necessary for these two XRI features (as well as any others),
> > 2) Draft the text that reserves XRI-specific syntax 
> > structures for specific
> > purposes.
> > 
> > =Drummond 
> > 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]