RE: [xri] public review comments

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

Draft response:

Comments from James Manger 10/21
http://lists.oasis-open.org/archives/xri-comment/200910/msg00000.html

* 4.1. Linked Resource Selection - uses poor examples.
*2.1.5. Element <Type> - is of limited use, should be replaced with a <Property> element.
* 2.2.1. Element <Link> - should be aligned with HTML structure of using attributes.
* 2.2.5. Element <URITemplate> - remove note about handling unknown variable names.

Response: The committee accepted all the comments and made the necessary changes to the draft.

---

Comments from Blaine Cook 10/23
http://lists.oasis-open.org/archives/xri-comment/200910/msg00001.html

* 2.2.1 - Link Element - should be aligned with HTML structure of using attributes.
* 2.2.5 - URITemplate Element - request to clarify language.
* 6 - XRD Sequence - request to drop the <XRDS> element.

Response: The committee accepted the first two items and made the necessary changes to the draft. The committee did not agree with the proposal to drop the <XRDS> element which is required for XRI use cases.

---

Comments from Santosh Rajan 11/8
http://lists.oasis-open.org/archives/xri-comment/200911/msg00003.html

* Change the XRD definition from describing a resource to "describing a set of resources that is available to a given entity".

Response: The committee rejected the proposal as it does not represent the design and purpose of the XRD document. In addition, the proposed definition uses web architecture terms incorrectly.

---

Comments from Peter Brown 11/8

* Have the requirements set out been met already by another existing standard? Namely, the ISO 13250 "Topic Maps".

Response: No, simplicity is a core requirement of XRD which is not met but existing standards such as Topic Maps or POWDER.

---

Comment from James Manger 11/10

* Proposal to make <Subject> element required and allow non-URI subject types to use extension child elements of <Subject>.

Response: <Subject> provide an optimized element for the core XRD use case of describing a single resource identified by a URI. The proposal does not provide for other subject types directly. Extensions are already possible today which make this change largely cosmetic. The TC prefers the current definition of the <Subject> element, and has made changes to the element prose to clarify that.

---

Comments from Santosh Rajan 11/10

* Change the cardinality of <Subject> element to 1 instead of 0 or 1 (or at least make it RECOMMENDED).

Response: See response to previous comment.

---

Comments from Jonathan Rees 12/10

* Add support for the HTTP Link header 'anchor' facility which allows specifying a different context URI for the link other than the one described by the XRD document.

Response: XRD is currently in line with HTML and ATOM in not supporting this feature. In addition, the TC does not have use cases to justify adding the feature.

---

Comments from Santosh Rajan 12/12

* The <Title> element should be moved inside the <Link> element as attribute, as in ATOM.

Response: Unlike ATOM, an XRD document does not have a language context. XRD has to be able to express multiple titles in different languages per link. This cannot be easily accomplished using attributes.