[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Thoughts on XRD-to-resource cardinality
Comments inline: -------------------------------------------------- From: "Drummond Reed" <drummond.reed@cordance.net> Sent: Wednesday, January 28, 2009 2:59 PM To: "'XRI TC'" <xri@lists.oasis-open.org> 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. Well, as I have stated in my previous mail, this is a well studied area in the Object Orientation, I suppose, and it still is one-XRD-to-one-resource. We have just defined a instantiation method by templating. > > 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). I am not sure about this. Think of this example. <XRD> <CanonicalID>https://sakimura.org/nat#12345678</CanonicalID> <About>https://google.com/sakimura</About> <About>https://id.mixi.jp/nat</About> <About>https://marimba.org/webmaster</About> <About>https://nri.co.jp/employee/n-sakimura</About> <link> .... </link> </XRD> How do you construct a valid template for this example? (Of course, the above XRD is just stating that owner of the CanonicalID allows him to be desribed by the uris in <About>, and not vice-versa.) > > 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? BTW, is this <Resource> element now semi-official? > > =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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]