[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: comments on XRD 1.0 wd9
From: Manger, James H
[mailto:James.H.Manger@team.telstra.com] 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]