[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 element. 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." and "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! :-) b.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]