I think a strong case can be made for both
EquivID and MapToID (or as I prefer preferredId) being moved to an extension
spec as they are not directly related to resolution. There is a perfect
forum for extension specs with the use of services.
With that said …. To get this thing
wrapped up I am ok with having these in the resolution spec. Just so long
as any touching or implication of touching CID is off the table.
From:
markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Saturday, August 25, 2007
5:25 PM
To: Barnhill, William
Cc: Chasen, Les; Drummond Reed;
xri@lists.oasis-open.org; Tan, William
Subject: Re: [xri] Direct
descendant vs. family descendant CIDs (was RE: [xri] Minutes: Special XRI TC
Telecon Noon PT Friday 2007-08-24)
I totally agree with that, I also think that the more elements we have, the more
difficult it will be to turn theory into practice and get applications to
handle everything right. That's why I'm STILL not sure if we need both EquivID
and MapToID.
I now also added a few lines to that page:
http://wiki.oasis-open.org/xri/XriCd02/SynonymSemantics
Markus
On 8/25/07, Barnhill,
William <
barnhill_william@bah.com> wrote:
I definitely see that the meaning of these ***Id
elements is being well-defined, but based on my experience observing other
implementations I suspect that with so many optional identifying elements there
will be several software projects that still use one of them for the wrong
purpose. My fear is that one of these catches on, or is integrated into a
well-adopted project (such as OpenId, Higgins, Eclipse), and then we are stuck
with an interoperability issue unless we can convince them to change.
How big an issue depends on how off-track the element use is, how many elements
are mis-used, and which ones. Part of this is also that I have heavy
micro-format leanings, so I'm attracted to the concept of one id element that
can have several roles, some of which are well-defined within the spec, the
rest of which are defined by spec extensions. That concept seems more
flexible, more easily understood by implementers, and more easily extensible.
With one element per purpose I also suspect we will continue to think up
purposes for which we need to add elements, though the frequency will fall off
fast as we cover more and more Id uses.
I'll bend with the wind and go whichever way the majority of the TC wants, but
wanted to raise my concerns.
Bill
-----Original Message-----
From: Chasen, Les [mailto:les.chasen@neustar.biz]
Sent: Sat 8/25/2007 11:14 AM
To: Barnhill, William; Markus Sabadello; Drummond Reed
Cc: xri@lists.oasis-open.org
Subject: 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 <http://xri.net/=les>
voice: =les/(+phone) <http://xri.net/=les/(+phone)>
chat: =les/skype/chat <http://xri.net/=les/skype/chat>
pibb me =les/+pibb <http://xri.net/=les/+pibb>
________________________________
From: Barnhill, William [mailto:barnhill_william@bah.com]
Sent: Saturday, August 25, 2007 9:53 AM
To: Markus Sabadello; Drummond Reed
Cc: Chasen, Les; xri@lists.oasis-open.org
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: markus.sabadello@gmail.com
on behalf of Markus Sabadello
Sent: Fri 8/24/2007 8:51 PM
To: Drummond Reed
Cc: Chasen, Les; xri@lists.oasis-open.org
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 <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
> > >
> > >
>
>
>
|