RE: Hole in XRD processing: Type matching

[Eran Hammer-Lahav <eran@hueniverse.com>]

(It might look like I am talking to myself here, but I am reporting back after each off-list conversation I am having)

We are considering two types of links between XRDs:

1. Include

An expansion of one document inside another. Because this is XML and a document with schema restrictions, we cannot do a simple include, but must come up with rules as to what exactly is being included and how it is expanded into the linking document. Currently, we define see-also as a very limited include which only includes <Link> elements, and only does so when no other links are found suitable.

Making include work as expected is going to be very hard because it requires a pre-fetch of all the linked XRDs recursively, and we will need to be explicit about what gets included. It gets even more complex when dealing with extensions which are expected to get included, but may have their own cardinality rules.

I don't think there is an easy way to make includes work without create a huge burden on developers (for example, includes require building a separate document store than the XML one because you need to be able to add more stuff to the tree that did not come from the original document, as well as to remove the 'see-also' or include elements).

2. Replace

An all or nothing approach where anything in the original document is ignored and a consumer simply gets replaced with another document elsewhere. The tricky part of a replace is how protocols should handle subject changes other than for trust verification. This of course can be left undefined by the XRD spec. A replace can be implemented as an element or a link, each with its own advantages and disadvantages.

Replace does not provide all the flexibility of an include but it does work consistently and satisfies the basic use case of having one XRD point to another. The processing instructions will be to first look for (zero or one) replace directives (element or link) and if found, ignore anything else and just fetch that other XRD.

I am purposely not using 'redirect' here because the term carries its own set of semantics from HTTP. Reinventing redirection in XRD is going to both bring up the redundancy with HTTP 3xx and the functionality of 3xx (temporary, permanent, multiple options, etc.). The main downside to this is that is clearly can be implemented with HTTP redirections and the only reason we have for why we need it is trust, which we leave undefined in the spec.

---

It seems to me that the best approach at this point is to go with 'Replace' and express it using a <Link> element with a custom relation type (instead of see-also). The processing instructions will require consumers to first look for the first such link and follow it instead of processing any other information in the XRD (after verifying trust of course). This will not give us the nice cardinality a schema provides but will also no require any additional element and trust rules. We can allow multiple 'replace' links by saying the consumer must follow the first but may try others in document order if the first fails to produce a valid XRD document.

Thoughts?

EHL




> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Wednesday, September 16, 2009 10:37 AM
> To: 'XRI TC'
> Subject: [xri] RE: Hole in XRD processing: Type matching
> 
> If it wasn't clear, this is a blocking issue and we cannot publish
> another draft of the spec until it is resolved.
> 
> Will and I had a long conversation about it last night and here are
> some additional thoughts:
> 
> * We have two clear use cases:
> 
> - The ability to delegate XRD descriptor for a local resource to
> another provider. While this can be done at the links level, we need it
> to be signed for trust purposes which means we need the "redirection"
> to happen inside a signed document. Since we only have one mechanism to
> do so (XRD), we need to express this inside XRD. For example, a site
> can point consumers to another company to manage all its XRD needs.
> 
> - The ability to define a local XRD and include in it descriptors from
> other documents. This is needed to override or supplement the
> information in either the local XRD or the included XRDs. For example,
> being able to delegate XRD services to another service which does not
> support some new XRD feature, but still add that locally before
> including the delegated information.
> 
> Right now, we have a well-defined solution that does not meet the
> expectations. See-also links currently only import <Link> elements from
> other XRD documents, and anything else in the linked XRD is ignored,
> including the <Subject>, <Alias>, and <Type>. <Subject> may be used for
> trust verification but undefined for anything else when following a
> see-also. This fails both use cases.
> 
> More too follow.
> 
> EHL
> 
> > -----Original Message-----
> > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> > Sent: Tuesday, September 15, 2009 9:32 PM
> > To: 'XRI TC'
> > Subject: [xri] Hole in XRD processing: Type matching
> >
> > I brought this up before but I didn't realize how much bigger the
> issue
> > is.
> >
> >
> > Currently, we say nothing about how consumers should treat the see-
> also
> > link in the context of Type matching (as opposed to Link selection).
> > Basically, we do not include see-also links for the purpose of
> resource
> > properties, only links. Furthermore, it doesn't address any
> extensions
> > at the XRD level (link extensions are covered).
> >
> > Consider this:
> >
> > <XRD>
> > 	<Type>http://example.com/type1</Type>
> > 	<Link>
> > 		<Rel>http://docs.oasis-open.org/xri/xrd/v1.0#see-also</Rel>
> > 		<URI>http://example.com/xrd2<URI>
> > 		<MediaType>application/xrd+xml</MediaType>
> > 	</Link>
> > </XRD>
> >
> > And xrd2:
> >
> > <XRD>
> > 	<Type required="true">http://example.com/type2</Type>
> > </XRD>
> >
> > In the example above, the consumer will ignore the see-also type, and
> > will continue to interact with the resource even if it doesn't
> > understand 'type2'.
> >
> > Another example:
> >
> > <XRD>
> > 	<Link>
> > 		<Rel>http://docs.oasis-open.org/xri/xrd/v1.0#see-also</Rel>
> > 		<URI>http://example.com/xrd2<URI>
> > 		<MediaType>application/xrd+xml</MediaType>
> > 	</Link>
> > </XRD>
> >
> > And xrd2:
> >
> > <XRD>
> > 	<Type>http://example.com/type1</Type>
> > 	<Link>
> > 		<Rel>http://example.com/rel1</Rel>
> > 		<URI>http://example.com/endpoint<URI>
> > 	</Link>
> > </XRD>
> >
> > In this case, the first XRD simply delegates its description to
> another
> > XRD. However, this delegation is limited to link selection only which
> > means a consumer looking for link of type 'rel1' will not process the
> > 'type1' information. This will lead to either incomplete information
> at
> > the time of processing the xrd2 link, or to failing to recognize (and
> > hence even look for such link) that the resource supports the 'type1'
> > functionality.
> >
> > ---
> >
> > None of the options to resolve this are great. This is the list I was
> > able to come up with:
> >
> > 1. Require the parsing of all linked XRDs for the purpose of
> > determining the resource attributes (XRD level). This doesn't scale
> > well, but might not be too bad since we are talking about building a
> > flat list of single values. It also solves the issue of XRD level
> > extensions which will also be collected.
> >
> > 2. Limit consumers to use the types from the first XRD only. This
> goes
> > against the architecture and breaks the main use case for see-also
> > which is delegating the entire descriptor.
> >
> > 3. Make the fetching of linked XRDs for the purpose of resource
> > attribute optional, but that conflicts with the use of the 'required'
> > attribute. It will create inconsistent behavior based on how a
> consumer
> > obtained an XRD.
> >
> > What makes <Type> so different from <Link> is that with links,
> > consumers know what they are looking for (often thanks to the use of
> > <Type>). But with XRD level resource attributes, the whole point is
> to
> > go over the list and discovery what is familiar.
> >
> > #1 is the only option that is consistent with the architecture but I
> am
> > worries about its implementation. I am not sure what is the right
> > solution.
> >
> > Ideas?
> >
> > EHL
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
> 
> 
> ---------------------------------------------------------------------
> 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