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

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









[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]