RE: [xri] Thoughts on XRD-to-resource cardinality

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

Eran, I'm a little behind with the sudden trip I'm taking but in reading
this over tonight I find myself agreeing with the conclusions the four of
you came to and liking the proposed element names. I wish I could be there
for further discussion tomorrow but I'll catch up next week.

=Drummond 

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Tuesday, January 27, 2009 10:21 PM
> To: Drummond Reed; 'XRI TC'
> Subject: RE: [xri] Thoughts on XRD-to-resource cardinality
> 
> This is an interesting idea but I am not sure we need to go this far.
> Brian, Breno, Dirk, and I had an interesting conversation about this
> today.
> 
> Ignoring the theoretical ideas and focusing on actual use cases, we have
> some clear requirements:
> 
> 1. Allow multiple resources to point (link) to a single XRD (with a single
> URI).
> 2. Allow an XRD to clearly state its subject.
> 3. Allow an XRD to establish its authority (via trust) to make claims
> about its subject.
> 4. Allow an XRD to declare how a set of URIs relate to each other (equiv,
> canonical, etc).
> 
> There is no clear use case for an XRD to:
> 
> 5. Allow an XRD to state multiple subjects, unrelated to one another.
> 6. Allow multiple entities (certificates) to sing a single XRD.
> 
> ---
> 
> Here is how each can be addressed. Define the following XRD-level elements
> (straw man names):
> 
> CanonicalURI - the canonical identifier of the XRD subject resource (0 or
> 1).
> EquivURI - an alias of the subject resource, a different URI to the same
> resource (0 or more).
> 
> 1. While resources can share any XRD, even with a stated subject, it will
> probably fail trust verification in most applications if the URI being
> discovered is not listed in one of the two URI elements above. I think we
> should name the kind of XRD that has no URI subject declared internally,
> and has its subject derived from the URI being discovered pointing to it.
> A sort of "uncommitted" XRD.
> 
> 2. The XRD can use any combination of the URI elements to declare its
> subject. Usually if it contains a single URI, it will use the
> CanonicalURI, and if more than one, it can have one canonical and many
> equiv, or just many equiv without clearly choosing a canonical.
> 
> 3. To make trust simple enough, there has to be a connection between the
> XRD subject and the subject of the certificate used to sign it. In theory,
> any one of the URIs can be signed, including an non-canonical one. But
> usually the canonical URI will be the one signed.
> 
> 4. The clear meaning of the two URI elements allow declaring how multiple
> URI relate to one another, while the XRD describes a single resource.
> 
> ---
> 
> This approach simply adds to what we have today the explicit ability to
> not state the subject of an XRD, and allow such uncommitted descriptor to
> be used by multiple resources.
> 
> We should discuss the elements names (I am not against the current ___ID
> elements, but they don't translate well to the non-identity use cases,
> even if the ID maps to the I in URI...), as well as more such URI
> relationships at the XRD level.
> 
> EHL
> 
> 
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Tuesday, January 27, 2009 10:00 PM
> > To: 'XRI TC'
> > Subject: [xri] Thoughts on XRD-to-resource cardinality
> >
> > I will be offline Thursday and Friday travelling to a memorial, so I
> > want to
> > contribute here on the list to advance today's discussion about
> > XRD-to-resource mapping
> > (http://wiki.oasis-open.org/xri/SelfServeAgenda#head-
> > a4044b7035eb441c2674549
> > d07ccaf27daed8970).
> >
> > As I said on the call, the concept of a one-to-many mapping between an
> > XRD
> > and the resources it describes is a mind-expander for those of us who
> > have
> > been living a one-XRD-to-one-resource worldview for a few years now.
> > But the
> > use case -- being able to get and cache one XRD to describe potentially
> > a
> > very large number of resources (such as an entire site) is compelling.
> >
> > Under a one-to-many mapping, I believe Eran's right that the concept of
> > asserting a synonym (not just CanonicalID but any synonym) pretty much
> > goes
> > away. The only synonym assertion I could see providing is some form of
> > aliasing template that would apply to the URIs of all the described
> > resources (e.g., every that maps to the http://foo.example.com/*
> > template
> > can all be mapped to the http://bar.example.com/* template).
> >
> > But that appears to be of limited use, and probably not appropriate for
> > assigning CanonicalIDs (which is usually a mapping from a reassignable
> > to a
> > persistent identifier).
> >
> > But the rest of the XRD metadata and Link metadata still seems
> > appropriate,
> > i.e., it applies as much to an individual resource (one-to-one mapping)
> > as
> > it does to a group of resources (one-to-many mapping).
> >
> > So what I'm wondering is if maybe there should be a clear way of
> > indicating
> > the cardinality of the XRD. In other words, a child element of the root
> > XRD
> > element that indicates whether it is it an individual XRD (one-to-one
> > mapping) or a group XRD (one-to-many mapping).
> >
> > If there was a choice between two mutually exclusive options for that
> > child
> > element, then all the other elements that are appropriate only for one
> > or
> > the other (CanonicalID, EquivID, URIMap, etc.) could follow as children
> > of
> > that element.
> >
> > Here's a simple example using the element names <Resource> and
> > <ResourceGroup>:
> >
> > INDIVIDUAL XRD:
> >
> > <XRD>
> >     <Expires>2009-01-01T08:30:00Z</Expires>
> >     <Resource>
> >         <CanonicalID>http://example.com/resource/1</CanonicalID>
> >         <EquivID>http://example.net/resource/1</EquivID>
> >     </Resource>
> >     <Type>http://example.com/type/profile_photo</Type>
> >
> >     <Link>
> >         <URI>http://example.com/resource/2</URI>
> >         <Rel>http://example.com/rel/profile</Rel>
> >     </Link>
> > </XRD>
> >
> > GROUP XRD:
> >
> > <XRD>
> >     <Expires>2009-01-01T08:30:00Z</Expires>
> >     <ResourceGroup>
> >         <URIMap>http://example.com/resource/*</URIMap>
> >     </ResourceGroup>
> >     <Type>http://example.com/type/photos</Type>
> >
> >     <Link>
> >         <URI>http://example.com/service/1</URI>
> >         <Rel>http://example.com/rel/some-group-service</Rel>
> >     </Link>
> > </XRD>
> >
> > Thoughts?
> >
> > =Drummond
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php