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: Fwd: [xri-comment] XRD: comments on XRD 1.0 wd9


FYI - if you want to receive these directly, subscribe to the XRI comment list.

=Drummond

---------- Forwarded message ----------
From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Tue, Oct 20, 2009 at 9:21 PM
Subject: [xri-comment] XRD: comments on XRD 1.0 wd9
To: "xri-comment@lists.oasis-open.org" <xri-comment@lists.oasis-open.org>


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




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