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

["Chasen, Les" <les.chasen@neustar.biz>]

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