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