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

["Markus Sabadello" <markus.sabadello@xdi.org>]

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
> >
> >