FW: Unified syntax proposal

["Wachob, Gabe" <gwachob@visa.com>]

---

• From: Drummond Reed <drummond.reed@onename.com>
• To: "Wachob, Gabe" <gwachob@visa.com>, Dave McAlpin <dave.mcalpin@epokinc.com>, Peter C Davis <peter.davis@neustar.biz>
• Date: Fri, 16 May 2003 16:09:10 -0700

[First, about moving this to the list, my proposal is to summarize all
of this in a posting as soon as the editors list is formed. =D]

Ah, fascinating conclusion Gabe: that "/" denotes the "start of a
resource", whereas dot-or-colon denotes a delegated identifier.

I arrived at a similar conclusion coming at it from exactly the opposite
direction: that "/" denotes the "end of a community". So
xri://a.b.c/:d:e:f  represents two communities: the community //a.b.c
and, under that, the community :d:e:f.

It's particularly accurate in the way it reflects the delegation
relationships and the act of federation. xri://a.b.c/:d:e:f/g  tells us
that //a.b.c and /:d:e:f are two separate communities that are not
federated. If the two federated by c DELEGATING to d (rather than c
CONTAINING d as / indicates), then the result would be
xri://a.b.c:d:e:f/g . Voila, the two communities are federated into one!

The difference between *delegation* and *ownership* was what I was
trying to get at in my earlier "aggregation" vs. "composition"
explanation. From a UML perspective, delegation expresses an aggregation
relationship (authority A is aggregating the identifiers of authority
B), whereas ownership expresses a composition relationship (the
identifiers in namespace B are assigned by authority A).

Does that make more sense?

Overall, I like both angles - slash means the start of a resource (every
community being a resource, of course) and the boundaries of an
identitier community. 

And on that note, I think it's time to start my weekend (and prepare to
move this thread to the new editor's list on Monday).

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Thursday, May 15, 2003 11:26 AM
To: 'Dave McAlpin'; Drummond Reed; 'Peter C Davis'
Cc: 'Sakimura, Nat'; Lindelsee, Mike; Marc LeMaitre
Subject: RE: Unified syntax proposal

Lets continue in this vein and we'll be sure to forward messages to the
archive. I dont want to stop in midthought.. Barring any surprises,
we'll be approving the formation of the subcmte this afternoon and then
we'll press really really hard to get the subcmte setup asap.

That being said, I think I have a conception for the '/' that makes
sense to me (and may be in fact what drummond is trying to get at).

It struck me that '/' denotes "something-ness" (huh?) That means that
wherever you see a '/', a "resource" is actually described. So, in the
XRI xri://1.2.3/a.b.c/d.e.f , we can know that there are three "things"
with identifiers:

xri://1.2.3 (the naming authority)
xri://1.2.3/a.b.c (something else)
xri://1.2.3/a.b.c/d.e.f (yet another thing, which is described by the
entire XRI)

Note that the first "thing" demarcated with a slash is the naming
authority which we give special semantics and resolution for.

This conceptualization of '/' doesn't mean that prefix substrings of an
XRI don't identify "resources", it just means that we can't infer that
from the identifier example above. All we can infer about these
identifiers (given the original xri example above) is that they
correspond to directory entries:

xri://1.2
xri://1.2.3/a.b
xri://1.2.3/a.b.c/d

I think this parallels Drummond's thinking.

So a.b.c can therefore be thought of as a "directoy delegation path"
whereas xri://a.b.c is a "naming authority" and xri://a.b.c/1.2 is a
resource who's directory delegatoin path is "1.2" relative to the naming
authority xri://a.b.c

Does *that* make senes now? Note that this is an orthogonal issue to the
distinction and the possible mixing of "." and ":".

        -Gabe

> -----Original Message-----
> From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com]
> Sent: Wednesday, May 14, 2003 4:52 PM
> To: 'Drummond Reed'; 'Peter C Davis'
> Cc: 'Wachob, Gabe'; 'Sakimura, Nat'; 'Lindelsee, Mike'; 'Marc
> LeMaitre'
> Subject: RE: Unified syntax proposal
>
>
> We should be having these conversations on the list.
>
> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@onename.com]
> Sent: Wednesday, May 14, 2003 4:40 PM
> To: Peter C Davis
> Cc: Wachob, Gabe; Dave McAlpin; Sakimura, Nat; Lindelsee, Mike; Marc
> LeMaitre
> Subject: RE: Unified syntax proposal
>
> Peter, responses inline:
>
> -----Original Message-----
> >From: Peter C Davis [mailto:peter.davis@neustar.biz]
> >Sent: Wednesday, May 14, 2003 12:21 PM
>
> >>Drummond Reed wrote:
> >>
> >><snip/>
> >>
> >>Correct me if I'm wrong, but from a resolution standpoint the
> difference
> >>is a big deal. A/B/C would never be cached as a whole
> because A would
> >>always resolve B and C locally. But A.B.C, or A:B:C, or A.B:C, or
> A:B.C
> >>can each be cached as a whole because they are federated names. And
> the
> >>difference between caching A.B.C and A:B:C is significant because
> there
> >>are no TTLs with persistent identifiers.
> >>
> >>
> >Hmmm.... not sure i am with you here.  Just because the naming
> >identifiers are persistant (or mixed), does not demand that the real
> >_network location_ of the resource remains unchanged, does
> it... or is
> >that your implication?
>
> No, you're right, although the identifier is persistent, it does not
> mean the network location of the resource hasn't changed. The big
> difference between delegation of persistent identifiers and
> reassignable
> identifiers comes down to the complexity of the resolution tree.
>
> Let's take the example of "foo.bar.baz" and "foo:bar:baz". In
> the first
> case, foo assigns identifier "bar" to resource 1 (R1) at location 1
> (L1). R1 then assigns identifier "baz" to R2 at L2. You now have four
> variables below "foo" in the tree of resolution of "foo.bar.baz" - R1
> controlling L1 and R2 controlling L2. If foo reassigns the identifier
> "bar" to R3 at L3, and R3 assigns the identifier "baz" to R4
> at L4, the
> whole tree has moved.
>
> Contrast this with "foo:bar:baz". In this case, "bar" and "baz" are
> persistent. The colon tells a parser that foo will not reassign "bar"
> and bar will not reassign "baz". So "foo:bar:baz" is for all
> intents and
> purposes a single identifier that refers to a single
> resource, R1. Which
> means the number of variables is reduced to exactly one: the current
> location, L.
>
> That's why I see such a "bright line" between persistent and
> reassignable identifier segments.
>
> >As for A.B:C  while I appreciate the simplicity, i wonder
> what relying
> >parties of C would do when authority for B changes?  Certainly we
> cannot
> >expect B to be obligated to maintain C indefinitely.  Consider the
> >authority lists.w3.org, and w3.org gets re-assigned to the IETF
> (hehe...
> >couldn't resist)...  they are not obligated to maintain "lists".
> >
> >I may be speaking apples and oranges, but I think the concept of
> >"reassignable identifiers delgating persitant identifiers" is
> troublesome.
>
> I could not agree with you more about the practical realities
> of having
> persistent identifiers assigned by authorities which are themselves
> identified by reassignable identifiers (in the v5
> Requirements doc this
> is what I called "relative persistence".) But it happens all the time.
> All the major web sites use persistent identifiers
> internally, but in a
> URI they are expressed relative to the website's DNS domain
> name, which
> I'm sure they consider "stable enough" from their
> perspective. I expect
> it may be fairly tough to convince them that they should be
> registering
> top level persistent identifiers with some URN or XRI registry.
>
> So the unified syntax proposal does not impose any architectural or
> operational philosophy about who should delegate what. It simply gives
> every identifier authority the option to delegate at any level using
> either a reassignable identifier (a dot) or a persistent identifier (a
> colon), and then let a 1000 flowers bloom. (Make that 10
> billion flowers
> ;-)
>
> =Drummond
>
>
>

---