[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes in wd11)
So I think you are saying simply that using EquivId I can establish that one XRD is equivalent to another XRD. However that does not mean that the other XRD is equivalent to the first XRD. @neustar*les may state that he is equivelelnt to =les with out any claim of =les being equivalent to @neustar*les. In other words this is a one-way claim of synonymy between two XRDs. OTOH, mapToId/mapFromId is also declaring synonymy between two XRDs but one that establishes a two-way claim. I honestly do not see a need to have both of these attributes. They seem to be close enough in meaning to almost be redundant. I would personally just have EquivId (because it is a more descriptive term) with the ability to validate a two-way claim. For example: XRD 1 has an EquivId that points to XRD 2 that establishes a one-way claim. This may be fine for some consuming applications. For those that need something stronger they could resolve for XRD 2 and look for another EquivId back to XRD 1. This establishes a two-way claim. With that said, I do not feel strongly enough about this. If the TC is ok with it I am ok with it. One note, You also add the additional statement for MapToId that the consuming application should use the CID (or QXRI) that is in the MapToId as the identifier for the first XRD. It seems to me that this implies that the XRD referred to by that MapToId is the successor XRD and therefore the first XRD should not be used for service selection. I am not sure you can really do that if we do not change resolution logic. contact: =les sip: =les/(+phone) chat: =les/skype/chat > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Wednesday, August 22, 2007 2:06 AM > To: Chasen, Les; Tan, William > Cc: 'XRI TC'; 'Andy Dale' > Subject: RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes in > wd11) > > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]