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






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