OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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
> Following are the minutes of the special unofficial XRI TC telecon
> at:
> Date:  Friday, 24 August 2007 USA
> Time:  12:00PM - 1:00PM Pacific Time
>     Dial In Number: 571-434-5750
>     Conference ID: 5474
> 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
> there is (now) relatively strong consensus on the use of these synonym
> elements (see below), and b) adding attributes to a single synonym
> does not enable control at the XML schema level of cardinality, which
> important for elements such as CanonicalID (and the proposed UseCID).
> * We had a long discussion about the underlying needs for applications
> store a persistent identifier for a resource, touching upon many
> potential scenerios: when they are constrained (by schema or data
> 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
> The
> only inputs that determined whether a Ref is following or not are the
> the refs= parameter, and the service endpoint selection parameters.
> 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
> 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
> 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
> roughly the following definition: "The purpose of this tag is to
> the
> preferred identifier for the target resource if that preferred
> is
> not the QXRI or CanonicalID. It is recommended that applications
> this
> identifier in their local account for future reference to this
> * Drummond proposed that the core underlying motivation is to support
> 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
> members who have specific views on this issue to post their views to
> SynonymSemantics page of the wiki.
> * There will be another followup call on this topic on the same
> number at 8AM PT/11AM ET Monday August 27th.
> =Drummond

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]