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

["Chasen, Les" <les.chasen@neustar.biz>]

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Friday, August 24, 2007 8:39 PM
> To: Chasen, Les; xri@lists.oasis-open.org
> Subject: Direct descendant vs. family descendant CIDs (was RE: [xri]
> Minutes: Special XRI TC Telecon Noon PT Friday 2007-08-24)
> 
> 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.


[Chasen, Les] I apologize if I missed when we in the TC we discussed or
traded emails on this new proposal.  I thought until yesterday we were
sticking with the original intent which you are calling direct
descendants below.  I simply do not recall ever discussing something
else.

> 
> 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
[Chasen, Les] 
What happens if @nuestar's cid is @!2 and @ootao has cid @!3?

This does bring up another question.  As I recall the intent of localId
it was to contain the local portion of the absolute cid.  Since we are
changing the cardinality of cid to be 0-1 should we change the
cardinality of the localId to 0-1?   

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