[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)
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]