[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: Single delegation character
As someone who has actually written parser code for XRIs, I don't think the marginal simplification of the single delegation character is worth it - its not much harder to look for one of a pair of delegation characters (ie . and : or * and :) than to test for one (ie just *).
What makes parsing hard is the cross references - but, IMHO, thats one of the most valuable aspects of XRI...
-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: Loren West [mailto:loren.west@epok.net]
> Sent: Thursday, June 10, 2004 11:37 AM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] RE: Single delegation character
>
>
> Thank you for clarifying the fact that we're only talking about
> the XRI-Authority part of the XRI. It has helped this thread
> get back to it's original topic.
>
> The original topic had to do with dropping the ":" as a
> sub-segment separator, and replacing it with "*:".
>
> I'm not a proponent of that change. Maybe because I don't
> understand the benefit of a single separator, but mostly
> because it adds clutter to MFIs.
>
> =Loren
>
> -----Original Message-----
> From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
> Sent: Thursday, June 10, 2004 10:49 AM
> To: Drummond Reed; xri@lists.oasis-open.org
> Subject: RE: [xri] RE: Single delegation character
>
>
> After discussing this with Drummond last night, it's clear that I've
> done a poor job explaining my understanding of this issue. I think
> Drummond and I reached consensus, so I'll give it one more shot here.
>
> First, I think the concept of "delegation" has almost no role
> if you're
> only talking about syntax. Delegation is only meaningful in
> the context
> of either resolution or local access. In pure XRI syntax, all we're
> talking about is successive levels of hierarchy.
>
> In a conventional URI, the slash ("/") character denotes hierarchy. If
> the URI contains an authority component, one important hierarchy is
> between the authority and the remainder of the path. For example, in
> http://www.example.com/foo, we can identify two hierarchical
> elements -
> the authority (www.example.com) and the path (/foo). In a URI like
> http://www.example.com/foo/bar, the path component (/foo/bar) is also
> hierarchical, but that's pretty much all we can say about it. We can't
> make any assumptions about delegation. (Incidentally, the only
> assumption about delegation made by 2396bis is between the authority
> component and the path, i.e. on the first slash. "Many URI schemes
> include a hierarchical element for a naming authority, such that
> governance of the name space defined by the remainder of the URI is
> delegated to that authority (which may, in turn, delegate it
> further)."
>
> In http://www.example.com/foo/bar, the authority component
> (www.example.com) contains a second level of hierarchy
> delimited by dot
> ("."). (It's not entirely clear to me why dot is allowed to act as a
> delimiter in the authority component by the current rules of 2396bis,
> but that's a different problem.) Similarly, XRIs provide second level
> delimiters in the xri-authority component via star ("*") and colon
> (":"). For example, in xri:@example*foo/bar, we have first level
> hierarchy between the xri-authority (@example*foo) and the
> path (/bar),
> and second level hierarchy within the xri-authority (between @ and
> example and between example and foo). Likewise with
> xri:@:1:2/foo, where
> : acts as the second level delimiter.
>
> In URIs, second level delimiters are defined only for special cases of
> the authority component, specifically for IP addresses and
> domain names.
> No second level delimiter is defined generally. XRIs, in contrast,
> reserve star and colon as second level delimiters throughout the XRI.
> For example, in xri:@:1:2/:3:4/:5:6, the first level of hierarchy is
> denoted by the slash, with special consideration for the
> leftmost first
> level element (the authority), and the second level of
> hierarchy within
> each component delimited by slashes is denoted by the colon. In other
> words, we can separate the above XRI into two logical components,
> authority and path (@:1:2 and /:3:4/:5:6). We can divide the path into
> two hierarchical elements, :3:4 and :5:6. We can further
> divide each of
> those into two second-level hierarchical elements (:3 and :4,
> and :5 and
> :6, respectively). At the generic syntax level that's all we can say,
> with the possible exception of namespace delegation between the
> authority and the rest of the path.
>
> Now, if we consider standard resolution, we CAN say more about
> delegation. Specifically we can say that in the authority
> component star
> and colon imply delegation. That's _not_ because of some intrinsic
> characteristic of star and colon, but rather because of the semantics
> defined for those characters specifically for the authority
> component by
> standard resolution. Note that in a different resolution protocol,
> delegation might not be implied.
>
> Similarly, local access protocols and/or local implementations can
> define delegation semantics for either first or second level
> delimiters
> in the path component, but that's outside the scope of the
> XRI spec. At
> the syntax level as defined by the spec, these characters only denote
> successive levels of hierarchy without respect to delegation.
>
> Dave
>
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Wednesday, June 09, 2004 6:05 PM
> > To: xri@lists.oasis-open.org
> > Subject: RE: [xri] RE: Single delegation character
> >
> > Dave, I was careful to qualify my entire point with the statement,
> "within
> > the XRI authority portion of an XRI". I never meant
> anything more than
> > that,
> > which is why I made that qualification.
> >
> > It is true that the proposed XRI addressing rules for the
> proposed XDI
> > metaschema carry this distinction further down into XDI documents,
> which
> > is
> > all the province of a different TC. However that proposal
> only applies
> > within the context of XDI, and only if the XDI TC decides on that
> > approach.
> >
> > =Drummond
> >
> > -----Original Message-----
> > From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
> > Sent: Wednesday, June 09, 2004 5:49 PM
> > To: Drummond Reed; xri@lists.oasis-open.org
> > Subject: RE: [xri] RE: Single delegation character
> >
> > 2396bis says slash ("/"), question mark ("?"), and number sign ("#")
> are
> > all hierarchy characters. These characters serve two
> purposes - first,
> > to make identifiers easier to read by using a common syntax and
> second,
> > to provide a uniform representation of relative references (and
> > consequently common algorithms for processing them).
> >
> > In @foo/bar/baz, I think all we can say about /bar/baz is a) it's
> > hierarchical and b) it's in a namespace controlled by the authority
> > represented by @foo. If we're using standard resolution, we can also
> say
> > that if @foo/bar/baz is resolvable, the mechanism(s) for
> accessing the
> > resource represented by /bar/baz is defined in an XRID
> associated with
> > foo.
> >
> > In @foo*bar/baz, all we can say for sure about @foo*bar is a) it's
> > hierarchical using the second level delimiter and b) it's the
> namespace
> > authority for /baz. If we're using standard resolution, we can
> > additionally say that @ is the namespace authority for foo,
> foo is the
> > namespace authority for bar, and the mechanism(s) for accessing the
> > resource represented by /baz is defined in an XRID
> associated with bar
> > (assuming the XRI is resolvable).
> >
> > None of this is all that different than Drummond's statement below,
> but
> > it doesn't support his conclusion. First, only the first slash has
> > defined semantics. After that we have no idea whether or not slash
> > represents "delegation" - that's completely determined by the local
> > access protocol and/or internal implementations. Second, * or ! or
> > whatever is only a second level hierarchical delimiter in
> the generic
> > syntax. Semantics are defined only if we're using standard
> resolution,
> > and then only in the authority component. Only in that special case,
> > i.e. in the authority component when standard resolution is
> employed,
> > does * or ! imply delegation.
> >
> > Dave
> >
> >
> > > -----Original Message-----
> > > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > > Sent: Wednesday, June 09, 2004 5:17 PM
> > > To: xri@lists.oasis-open.org
> > > Subject: RE: [xri] RE: Single delegation character
> > >
> > > I agree with Peter's characterization of the meaning of the
> > distinction,
> > > and
> > > I believe that, within the XRI authority portion of an XRI, this
> > > distinction
> > > applies to all contexts. For example, in pure XRI technical terms,
> the
> > > distinction between "@foo/bar/baz" and "@foo*bar/baz" (to use star
> as
> > an
> > > example of the delegation character) is that:
> > >
> > > * In "@foo/bar/baz", both "/bar" and "/bar/baz" are
> identifiers for
> > > resources assigned by the identifier authority "@foo".
> > >
> > > * In "@foo*bar/baz", both "@foo" and "@foo*bar" are identifier
> > > authorities,
> > > and the latter is the identifier authority responsible for
> identifying
> > the
> > > resource "/baz".
> > >
> > > So essentially slash is the "hierarchy character" (taking
> our queue
> > from
> > > 2396bis BNF) that does NOT delegate authority, as opposed to star
> (or
> > > whatever delegation character we decide on) which explicitly
> delegates
> > to
> > > another identifier authority.
> > >
> > > =Drummond
> > >
> > >
> > > -----Original Message-----
> > > From: Peter C Davis [mailto:peter.davis@neustar.biz]
> > > Sent: Monday, June 07, 2004 7:25 AM
> > > To: Loren West
> > > Cc: 'Fen Labalme'; xri@lists.oasis-open.org
> > > Subject: RE: [xri] RE: Single delegation character
> > >
> > > I think of the distinction (highly simplified) as:
> > >
> > > a slash denotes a resource in the context of an authority
> (@idc/fen)
> > > while the "delegation char" is a resource authority.
> > >
> > > subtle but important distinction.
> > >
> > > --- peterd
> > >
> > > On Mon, 2004-06-07 at 01:46, Loren West wrote:
> > > > You're right, the dot means delegation in the authority section.
> > > > I was referring to your statement about the slash
> having specific
> > > > meaning (you said it's the stuff @idcommons knows about fen).
> > > >
> > > > =Loren
> > > >
> > > > -----Original Message-----
> > > > From: Fen Labalme [mailto:fen@idcommons.org]
> > > > Sent: Friday, June 04, 2004 6:25 PM
> > > > To: Loren West
> > > > Cc: xri@lists.oasis-open.org
> > > > Subject: Re: [xri] RE: Single delegation character
> > > >
> > > >
> > > > I don't believe I have. In the authority section (before the
> first
> > > > forward slash) dot means delegation. Am I not correct?
> > > >
> > > > Loren West wrote:
> > > > > I understand that you have attached additional semantics to
> > > > > the identifiers beyond the scope of the XRI TC, and it's why
> > > > > you're reluctant to ask users if they prefer a syntax
> > > > > that they may be more familiar with.
> > > > >
> > > > > Another example of the problems associated with encoding
> > > > > semantics into identifiers.
> > > > >
> > > > > One could argue that XRI is here because of the
> > > > > semantics embedded within existing identifier systems,
> > > > > and it's why I'm fairly sensitive about keeping them to
> > > > > an absolute minimum within the XRI TC.
> > > > >
> > > > > =Loren
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Fen Labalme [mailto:fen@idcommons.org]
> > > > > Sent: Friday, June 04, 2004 5:12 PM
> > > > > To: Loren West
> > > > > Cc: xri@lists.oasis-open.org
> > > > > Subject: Re: [xri] RE: Single delegation character
> > > > >
> > > > >
> > > > > Yes, I agree that @idcommons/fen and @idcommons*fen could be
> > defined
> > > to
> > > > > be equivalent, but we have a real reason that we want
> then to be
> > > > > different. The ability to explicitly state that
> @idcommons*fen
> is
> > an
> > > > > authority delegated to fen and @idcommons/fen is stuff
> @idcommons
> > > knows
> > > > > about fen enables a useful differentiation.
> > > > >
> > > > > This still leaves the door open for some communities to define
> > that
> > > > > e.g., @epok/loren defines an authority loren
> delegated by epok,
> > but
> > > > > that's a choice up to the community. I'd rather not
> make it in
> > the
> > > > syntax.
> > > > >
> > > > > Fen
> > > > >
> > > > > Loren West wrote:
> > > > >
> > > > >>Actually, @idcommons/fen is anything @idcommons wants it to
> > > > >>be - including a delegation to a different endpoint that
> > > > >>fen has control over.
> > > > >>
> > > > >>It could work the same as @idcommons*fen. I believe a user
> > > > >>given this option will choose it over bang or splat, and
> > > > >>it would be a shame if you're conducting a survey to leave
> > > > >>it out.
> > > > >>
> > > > >>The XRI specification says nothing about what @idcommons/fen
> > > > >>means, and very little about what @idcommons*fen means
> > > > >>other than it's a delegated means of obtaining an endpoint.
> > > > >>
> > > > >>It specifically excludes the concept of identity, or what
> > > > >>one identity knows about another identity, or who owns what,
> > > > >>or where control lies.
> > > > >>
> > > > >>=Loren
> > > > >>@idcommons*Loren
> > > > >>@idcommons/Loren
> > > > >>
> > > > >>The above examples may point to 3 different places, or to
> > > > >>the same place. There isn't any expression that I have
> > > > >>control of any of these places.
> > > > >>
> > > > >>I believe that as soon as you express that information within
> > > > >>an identifier you get yourself into trouble. It's complex
> > > > >>information, and changes at a different rate than the
> > > > >>identifier (which means it de-stabilizes the identifier
> > > > >>when it changes).
> > > > >>
> > > > >>It's meta-data about the resource pointed to by the
> > > > >>identifier, and outside the scope of this TC.
> > > > >>
> > > > >>=Loren
> > > > >>
> > > > >>-----Original Message-----
> > > > >>From: Fen Labalme [mailto:fen@idcommons.org]
> > > > >>Sent: Friday, June 04, 2004 3:17 PM
> > > > >>To: Loren West
> > > > >>Cc: xri@lists.oasis-open.org
> > > > >>Subject: Re: [xri] RE: Single delegation character
> > > > >>
> > > > >>
> > > > >>Loren West wrote:
> > > > >>
> > > > >>
> > > > >>>Fen - while you're at it, you should try asking if
> they prefer
> > > > >>>@idcommons/fen to either of the above. That works regardless
> > > > >>>of the change to the spec (if any).
> > > > >>
> > > > >>
> > > > >>No, Loren - it doesn't work. Unless we make / the delegation
> > > character
> > > > >>( which I think would be a very bad idea). @idcommons/fen is
> what
> > > > >>idcommons authority knows about fen, as opposed to
> @idcommons!fen
> > in
> > > > >>which idcommons delegates to the fen authority, which
> is what we
> > want.
> > > > >>
> > > > >>
> > > > >>
> > > > >>>I prefer bang over splat, and admit to printing a "bang name"
> > > > >>>on my business card in the past.
> > > > >>
> > > > >>
> > > > >>Yeah, I had one, too. 1982 or so. I kinda like
> bang, too, but
> > I'm a
> > > > >>geek. I'm looking forward to this weekend (survey)
> to kind out
> > what
> > > > >>normal people think.
> > > > >>
> > > > >>=Fen
> > > > >>
> > > > >
> > > > >
> > > > > 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
> > > .
> > >
> > >
> > >
> > > 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
> .
>
>
>
>
> 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.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]