From:
markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Saturday, August 25, 2007
5:27 PM
To: Chasen, Les
Cc: Drummond Reed;
xri@lists.oasis-open.org
Subject: Re: [xri] RE: Direct
descendant vs. family descendant CIDs (was RE: [xri] Minutes: Special XRI TC
Telecon Noon PT Friday 2007-08-24)
On 8/25/07, Chasen,
Les <les.chasen@neustar.biz>
wrote:
> -----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
> > >
> > >
>