Title: RE: [xri] Direct descendant vs. family descendant CIDs (was RE: [xri]
Minutes: Special XRI TC Telecon Noon PT Friday 2007-08-24)
We are beginning to get several **Id
elements but if their purpose is clear and unambiguous I am not sure how it
hurts interoperability. The equivId concept is starting to grow on
me. This is a nice way to publish identifiers to yourself in other
communities like linkedin, facebook etc.
I am also growing warmer to the concept of
the other Id attribute that Drummond is currently calling useCID. I am
completely against the current write up that says the value in this tag should
be used as the persistent cid by the consuming application. I think this
is wrong to even imply to consuming applications. They should use the cid
(the persistent primary key) of the XRD they queried. I am however thinking
that it would be a powerful feature to be able to tell a consuming application
my preferred identifier. This, along with equivId, provide a mechanism
for a consuming application to recognize me when I log in using different
identifiers. That could be a strong mapping tool.
I encourage everyone to review http://wiki.oasis-open.org/xri/XriCd02/SynonymSemantics
and add your opinions. You will see a section at the bottom
where Wil and I have added some thoughts.
contact: =les
voice: =les/(+phone)
chat: =les/skype/chat
pibb me =les/+pibb
From: Barnhill,
William [mailto:]
Sent: Saturday, August 25, 2007
9:53 AM
To: Markus Sabadello; Drummond
Reed
Cc: Chasen, Les;
Subject: 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: on behalf of Markus Sabadello
Sent: Fri 8/24/2007 8:51 PM
To: Drummond Reed
Cc: Chasen, Les;
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 <> 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:]
> > Sent: Friday, August 24, 2007 4:26 PM
> > To: Drummond Reed;
> > 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:]
> > > Sent: Friday, August 24, 2007 6:12 PM
> > > To:
> > > 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
> > >
> > >
>
>
>
