XRD: comments on XRD 1.0 wd9

Comments on XRD 1.0 working draft 9 (15 Oct 2009):

Firstly, I would like to congratulate the editors on a well structured and clearly written specification.

§4.1. Linked Resource Selection uses very poor examples. Invariably, the <Rel> value should be the primary criteria for selecting a link, with <MediaType> a useful secondary criteria. There is almost no reason to select a link based on a “URI matching a pattern” — that clashes with idea that URLs are (somewhat) opaque, and tramples the rights of the owner of a URL space to assign URLs as they choose. Only slightly less harmful is the example of selecting links with an image media-type. That suggestion just raises doubts in an XRD provider’s mind that a link for, say, some highly specialised relationship might be selected in an inappropriately context just because it uses a common media-type; or it might not be selected when it should be just because it omitted the <MediaType> hint.

I can imagine cases where I would want to find links using, say, image/gif when upgrading images to PNGs; or links to http://example.net/ when migrating everything to https — but these are editing tasks, not “normal” use of XRDs, so shouldn’t be examples in the specification.

§2.1.5. Element <Type> only allows properties of the resource to be URIs. There doesn’t seem to be any way to supply name=value properties for the resource, despite this being how properties (and metadata) are defined in most other contexts. Perhaps a new <name>value</name> child element of <XRD> is supposed to be defined for each such property by whatever specification needs it. I would have thought, say, a <Property name=”anyURI”>value</Property> element would be really useful in a generic resource descriptor syntax.

§2.2.1. Element <Link> uses child elements for <Rel>, <MediaType>, and <Title>. The analogous <link> elements in HTML and Atom use attributes instead of child elements. If there a good reason why XRD cannot be more consistent with those other (existing and widely deployed) specifications?

§2.2.5. Element <URITemplate>. Any template syntax will have rules on handling unknown variable names (which better allow them to be ignored for forward-compatibility) so the phrase about ignoring <Link> elements that “contain unknown variable name” should be removed.

P.S. The persistent/current/previous locations listed at the top of the spec do not work (eg http://docs.oasis-open.org/xri/xrd/v1.0/wd09/xrd-1.0-wd09.html returns 404 Not Found). I used http://www.oasis-open.org/committees/download.php/34724/xrd-1.0-wd09.html.

James Manger
James.H.Manger@team.telstra.com
Identity and security team — Chief Technology Office — Telstra

xri-comment message