RE: [xri] Direct descendant vs. family descendant CIDs (was RE: [xri] Minutes: Special XRI TC Telecon Noon PT Friday 2007-08-24)

["Barnhill, William" <barnhill_william@bah.com>]

Title: RE: [xri] Direct descendant vs. family descendant CIDs (was RE: [xri] Minutes: Special XRI TC Telecon Noon PT Friday 2007-08-24)

As I mentioned in the earlier email I think we have too many **Id elements and that it will hurt us in interoperability.  That said I'd prefer direct desc. as well, for the same reason that Markus stated.

Bill

-----Original Message-----
From: markus.sabadello@gmail.com on behalf of Markus Sabadello
Sent: Fri 8/24/2007 8:51 PM
To: Drummond Reed
Cc: Chasen, Les; xri@lists.oasis-open.org
Subject: Re: [xri] Direct descendant vs. family descendant CIDs (was RE: [xri] Minutes: Special XRI TC Telecon Noon PT Friday 2007-08-24)

I also think both is fine. In 99% of all cases it will be "direct"
descendants anyway.

Right now I have a slight preference for the tight version (NOT allowing
what you call "family" descendants), because with all those synonym elements
we are discussing I feel there is really no need to mess with the
CanonicalID itself. But I don't really care...

Markus

On 8/24/07, Drummond Reed <drummond.reed@cordance.net> wrote:
>
> Les, this requires that each CID being a direct child of the parent CID.
> That's fine if we decide to require that. What we discussed on the call is
> an equally veriable but more flexible rule where each CID must consist of
> valid subsegments from all of its parents.
>
> For example, if @cordance has cid = @!1 but also has LocalID !2 and !3,
> and
> @cordance*drummond has LocalID !4, then any of the following three
> identifiers would be verifiable CanonicalIDs for @cordance*drummond:
>
>         @!1!4
>         @!2!4
>         @!3!4
>
> I'd call this approach "family descendants" and the other approach "direct
> descendants". The only reason I suggest considering family descendants is
> that it provides more flexibility in the assignment of CanonicalIDs at
> lower
> levels in the resolution chain. OTOH, if we want to be more restrictive
> and
> require direct descendants, that's fine too (I'm pretty sure they would be
> easier and faster to verify).
>
> How do others feel?
>
> =Drummond
>
> > -----Original Message-----
> > From: Chasen, Les [mailto:les.chasen@neustar.biz]
> > Sent: Friday, August 24, 2007 4:26 PM
> > To: Drummond Reed; xri@lists.oasis-open.org
> > Subject: RE: [xri] Minutes: Special XRI TC Telecon Noon PT Friday
> 2007-08-
> > 24
> >
> > We also got sidetracked into a conversation on CID verification that I
> > think will need to get re-visited.  Drummond explained how it is
> > possible for CID verification to pass if a parent XRD does not contain a
> > CID while the child does.  The exact scenario discussed was
> > @cordance*Drummond*home where @cordance and *home have CIDs but
> > *Drummond does not ... but cid verification still passes.
> >
> > I think this is wrong and against the original intent of cid
> > verification.  We MUST verify that every XRD in a hierarchical chain
> > verify with the parent XRD.  This means that every XRD must have a CID
> > and each CID must contain the parent node in it's fully qualified CID.
> > So if @cordance has cid = @!1 then *Drummond must have a CID that begins
> > with @!1.  If we assume *drummond's cid is @!1!2 then *home needs to
> > have a cid that starts with @!1!2.
> >
> > contact: =les
> > sip: =les/(+phone)
> > chat: =les/skype/chat
> >
> >
> >
> > > -----Original Message-----
> > > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > > Sent: Friday, August 24, 2007 6:12 PM
> > > To: xri@lists.oasis-open.org
> > > Subject: [xri] Minutes: Special XRI TC Telecon Noon PT Friday
> > 2007-08-24
> > >
> > > Following are the minutes of the special unofficial XRI TC telecon
> > held
> > > at:
> > >
> > > Date:  Friday, 24 August 2007 USA
> > > Time:  12:00PM - 1:00PM Pacific Time
> > >
> > > TO ACCESS THE AUDIO CONFERENCE:
> > >     Dial In Number: 571-434-5750
> > >     Conference ID: 5474
> > >
> > > ATTENDING
> > >
> > > Wil Tan
> > > Markus Sabadello
> > > Les Chasen
> > > Drummond Reed
> > >
> > >
> > > The subject of the call was the current synonym semantics proposal at:
> > >
> > >     http://wiki.oasis-open.org/xri/XriCd02/SynonymSemantics
> > >
> > > Key points from the call:
> > >
> > > * We briefly discussed Bill Barnhill's proposal to the list but the
> > > conclusion was that: a) we don't want to change the definitions of
> > > LocalID,
> > > CanonicalID, and Ref due both to the installed base and to the fact
> > that
> > > there is (now) relatively strong consensus on the use of these synonym
> > > elements (see below), and b) adding attributes to a single synonym
> > element
> > > does not enable control at the XML schema level of cardinality, which
> > is
> > > important for elements such as CanonicalID (and the proposed UseCID).
> > >
> > > * We had a long discussion about the underlying needs for applications
> > to
> > > store a persistent identifier for a resource, touching upon many
> > different
> > > potential scenerios: when they are constrained (by schema or data
> > store)
> > > to
> > > having only one, when they can keep alternates, when they need to know
> > > equivalence relationships, etc.
> > >
> > > * We also discussed the use cases that require a target resources to
> > > merge,
> > > migrate, or simply associate identifiers, such as an individual moving
> > > from
> > > one community to another or two businesses merging.
> > >
> > > * We established that have consensus about the purpose and uses of
> > Ref.
> > > The
> > > only inputs that determined whether a Ref is following or not are the
> > > QXRI,
> > > the refs= parameter, and the service endpoint selection parameters.
> > The
> > > cid
> > > parameter will NOT affect affecting Ref processing.
> > >
> > > * We also have consensus that EquivID should have zero-or-more
> > > cardinality,
> > > is used to express equivalence relationships between identifiers, and
> > can
> > > be
> > > used in conjunction with the priority attribute to express the
> > priority of
> > > such equivalence assertions.
> > >
> > > * Where we do not have consensus yet is if or how an XRD should enable
> > > expression of a "stronger than equivalence" mapping relationship
> > between
> > > two
> > > identifiers. Such a relationship might be called "directional",
> > > "precessor/successor", "migration", "replacement", "preference",
> > > "redirect",
> > > or many other terms.
> > >
> > > * Les proposed that we define a PreferredID element for this purpose
> > with
> > > roughly the following definition: "The purpose of this tag is to
> > express
> > > the
> > > preferred identifier for the target resource if that preferred
> > identifier
> > > is
> > > not the QXRI or CanonicalID. It is recommended that applications
> > retain
> > > this
> > > identifier in their local account for future reference to this
> > resource."
> > >
> > > * Drummond proposed that the core underlying motivation is to support
> > the
> > > need of XRD authors to inform consuming applications that they should
> > > associate two primary global foreign keys for a resource.
> > >
> > > * After 2.5 hours of discussion, we agreed that next step is for all
> > TC
> > > members who have specific views on this issue to post their views to
> > the
> > > SynonymSemantics page of the wiki.
> > >
> > > * There will be another followup call on this topic on the same
> > telecon
> > > number at 8AM PT/11AM ET Monday August 27th.
> > >
> > > =Drummond
> > >
> > >
>
>
>