I think I recall reading somewhere that if I registered two i-names under the same i-number (like I have with @free and @on-line), then it would be appropriate for their XRDs to have <LocalID>s referencing each other (*on-line and *free). The only reason why the GRS does NOT do it is for privacy reasons I think?
It seems the new EquivID is really a superset of LocalID. I.e. for every LocalID you could also have an EquivID with the absolute version of the same identifier...
Markus
On 8/25/07, Chasen, Les <> wrote:
That is a good question … I never
liked the tag. If it has morphed into something that represents any local
synonym than that is even more reason that it cannot be used in CID
validation.
contact:
=les
voice
: =les/(+phone)
chat:
=les/skype/chat
pibb me
=les/+pibb
From:
[mailto:
] On Behalf Of Markus Sabadello
Sent: Saturday, August 25, 2007
5:27 PM
To: Chasen, Les
Cc: Drummond Reed;
Subject: Re: [xri] RE: Direct
descendant vs. family descendant CIDs (was RE: [xri] Minutes: Special XRI TC
Telecon Noon PT Friday 2007-08-24)
The way I always understood LocalID was that it not only contains the local
part of the CID, but also other local synonyms. If it was just for the CID,
then why did you guys introduce it in the first place?
Markus
On 8/25/07, Chasen,
Les <>
wrote:
> -----Original
Message-----
> From: Drummond Reed [mailto:]
> Sent: Friday, August 24, 2007 8:39 PM
> To: Chasen, Les;
> 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:
]
> > 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
> > >
> > >
>
