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: RE: [xri] public review comments

Draft response:

Comments from James Manger 10/21

* 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

* 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

* 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.

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