RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes in wd11)

["Drummond Reed" <drummond.reed@cordance.net>]

Les, you're not missing anything, it's just the limited bandwidth of email
(and/or my inability to express exactly what I mean). I'll try to make it
clearer.

When I say "non-directional", I mean that EquivID is expressing that neither
the source ID or target ID should take precedence over the other -- they are
pure peers. And by "directional", I mean that MapToID is expressing that the
target ID SHOULD take precedence over the source ID (and MapFromID expresses
the inverse).

So an EquivID element in XRD #1 pointing to the CanonicalID of XRD #2 is
indeed a pointer from one to the other, but the semantics are only that both
IDs represent the same resource, period. For example, the XRD for
@cordance*drummond could have an EquivID pointing to the QXRI or CanonicalID
of =drummond and the semantic interpretation would simply be, "@cordance
says that @cordance*drummond represents the same resource as =drummond".

A consuming application can simply take this statement at face value (for
example, if it has its own reasons to already trust @cordance as an
authority), or it can ask a resolver to verify it by seeing if it can find a
statement saying that "= says that =drummond represents the same resource as
@cordance*drummond" (meaning find an EquivID element in the XRD for
=drummond that points to the QXRI or CanonicalID of @cordance*drummond).

However, if @cordance*drummond had a MapToID pointing to the QXRI or
CanonicalID of =drummond, that statement would express that "@cordance says
that consuming applications should use [QXRI or CanonicalID] of =drummond
when referring to the resource known as @cordance*drummond". Again, a
consuming application can take this statement at face value, or it can ask
an XRI resolver to verify it to see if can find a statement saying
"=drummond says that consuming applications should use [QXRI or CanonicalID]
of =drummond when referring to the resource known as @cordance*drummond"
(meaning find a MapFromID element in the XRD for =drummond that points to
the QXRI or CanonicalID of @cordance*drummond).

Hope this helps,

=Drummond 

> -----Original Message-----
> From: Chasen, Les [mailto:les.chasen@neustar.biz]
> Sent: Tuesday, August 21, 2007 8:21 PM
> To: Drummond Reed; Tan, William
> Cc: XRI TC; Andy Dale
> Subject: RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes in
> wd11)
> 
> I must be missing something ... I don't understand how you can say
> EquivId is non-directional.  It is defined in one XRD pointing to
> another XRD.  That seems directional to me.   XRD 1 is equivalent to XRD
> 2 but XRD 2 is not equivalent to XRD 1.
> 
> contact: =les
> sip: =les/(+phone)
> chat: =les/skype/chat
> 
> 
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Tuesday, August 21, 2007 7:29 PM
> > To: Tan, William
> > Cc: 'XRI TC'; 'Andy Dale'
> > Subject: RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes in
> > wd11)
> >
> > Wil, you wrote:
> >
> > > I understand and agree that EquivID is p2p and non-directional,
> while
> > > MapToID/MapFromID are directional. I also understand that it would
> be
> > > Nice to be able to express an AKA relationship using a
> non-directional
> > > element. However, I'm not sure if the use case is a strong one.
> > > Generally, I would prefer to leave these to an extension (the X in
> XRDS)
> > > since it doesn't affect the core resolution behavior; my compiler
> has
> > > detected an "unreferenced local variable named EquivID".
> >
> > My preference is strongly to include EquivID in the base XRD namespace
> > because this is the only means we will be providing to express
> > non-directional, p2p relationships between identifiers. Again, the
> purpose
> > of this element is to enable direct equivalence mappings between
> > identifiers
> > with no overloading of either: a) resolution semantics, or b) mapping
> > (replacement) semantics.
> >
> > To leave this element out of the base XRD namespace would be to invite
> > lots
> > of non-standard ways to express a very basic concept.
> >
> > > I also don't understand how you could use EquivID to express
> directional
> > > equivalence without MapToID/MapFromID. Unless, of course, you encode
> > > directionality into an attribute of EquivID, but that IMO is less
> > > preferable to having separate elements.
> >
> > I'm not sure who may have given the impression that EquivID could be
> used
> > to
> > provide directional equivalence; I've always said that its purpose was
> > non-directional, and that directional equivalence should use
> > MapToID/MapFromID. I agree with you that separate elements for
> > non-directional and directional equivalence is much more precise, and
> > makes
> > it easier for communities and applications to set policies around
> their
> > use
> > of these synonym types.
> >
> > =Drummond