OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri-comment message

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

Subject: XRD: Comments on xrd-1.0-cd01

2.2.1 - Link Element

I'd like to re-iterate the suggestion that the <Link> element should
use attributes for the core, well, attributes. Rel, MediaType, URI,
and URITemplate are all zero or one associations, and as such should
be attributes, not elements. Moving these elements into the attribute
space does not prevent elements from extending the Link element.

Since the deployment space for XRD is in no small part the scripting
world, the use of attributes significantly lowers the barrier to entry
for idle experimentation (and thus adoption). Furthermore, it would
enable the XRD Link element to parallel the HTML link element, which
is well-understood, widely deployed, and the basis for the XRD Link

2.2.5 - URITemplate Element

The following lines:

"If a template uses an unknown syntax or contains unknown variable
names (without rules on how to handle such variables), the parent
<Link> element SHOULD be ignored."


"Applications that wish to utilize the template mechanism need to
define the variable vocabulary for each relation type, as well as the
template syntax and processing rules."

are confusing and should be removed. In addition, the following text:

"The template syntax and vocabulary are dependent upon the combination
of the application through which the XRD document is obtained, and the
link relation type indicated by the <Rel> child element of the
corresponding <Link>."

should be broken out of the first paragraph. It's sufficient alone to
describe how the URITemplate syntax is defined, but is currently lost
in the above two sentences (I only understood what was going on here
until chatting with Eran. A more careful reading would have prevailed,
but a casual reading left me completely confused).

6 - XRD Sequence

This seems unnecessary. Applications serving XRD documents that are
intelligent enough to combine multiple XRD documents should be able to
combine those documents into a single XRD. Documents that describe
multiple Subjects with differing Links should be available at
different URIs. The example I would cite here is HTML; while it might
have been useful in some contexts to have a multi-document "HTMLS"
(compare with XRDS), or multi-document feeds like "ATOMS" (MOLECULE?),
such documents would be more difficult to parse and unnecessarily
cumbersome for providers and consumers alike.

Other than that, looks great! :-)


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