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.
