[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Feedback on the XRD specification draft
FYI From:
webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of DeWitt
Clinton Thank you for the detailed reply, Eran. I'll save a
detailed response to your comments until after the spec leaves the TC and is
open for public review. However, the TC might agree that my feedback
introduces no new intellectual property considerations, as all I'm
suggesting is that the XRD format follow pre-existing standards, and hence
hopefully this feedback might be considered even before the spec is completed. Really the essence of what I'm encouraging is twofold.
First, that the XRD specification should follow pre-existing standards
because doing so offers substantial non-technical advantages, and second that
those pre-existing standards in fact offer a technical advantage. In
other words, it's a win/win to follow prior art here and not invent something
new. Regarding the first, the proposed XRD <Link> element
is not just different than HTML or Atom <link>, it feels arbitrarily different.
Given the overwhelming popularity of HTML and Atom <link>, it seems
to me that the burden should be on the TC to present a convincing case why
prior art can not work for XRD. Note that I'm not saying "is not
optimal", I'm intentionally saying "not work." My back of
the envelope math suggests that there are roughly a trillion <link> tags
already existing in the wild in HTML alone (more if you count Atom feeds).
That's a lot of precedent, and it means that there are a lot of people
that already know how to generate and parse them.
The cognitive overhead of learning a new syntax and naming
convention just for this one specification is non-negligible, and
further, inventing a new format to do the same thing inhibits interoperability
and reuse. Regarding the second, I feel that the proposed XRD
<Link> element is actually technically inferior to the HTML and Atom
<link> element. The presence of multiple zero-to-many child
elements (MediaType, URI, URITemplate, etc), and the out-of-document-order
ordering introduced by 'priority' do in fact make the XRD <Link> element
harder to parse and harder to use. I say this with confidence having now
written a partial parser for the XRD <Link> element and having seen the
complexity it creates firsthand. That said, I'm willing to entertain the notion that my
experience implementing and using an XRD parser was not representative.
Can you point me to other (preferably open source) implementations of an
XRD-based client? Thanks again for the reply! -DeWitt On Fri, Aug 21, 2009 at 11:42 AM, Eran Hammer-Lahav <eran@hueniverse.com>
wrote:
This is not how current links work. Both HTML and HTTP allow
multiple rel values (space delimited) on a single link. HTTP Link header
explicitly allows for multiple variables on a single link as well (multiple
types, etc.). The only new thing here is allowing multiple URIs which has been
proven convenient. I agree that it makes it easier for XRD providers than
consumers.
Given #1, this will not be very practical. Repeating
attributes multiple times isn't pretty and putting multiple values into a
single attribute is a known problem and requires more parsing of value strings.
I understand the desire to express XRD in JSON but it has never been a
requirement for XRD. XRD has good reasons to use XML (and I don't think any of
us want to have the XML vs JSON debate here) which is at the core of XRD's
extensibility model. After all, that's what the X in XRD is for.
We are going to soften the text about priorities in the spec
and make it a lot simpler and shorter. Right now the spec is pushing XRD
providers to use it but the next text will simple mention it as an optional
feature. We are still debating whether clients *must* obey priorities or
*should*.
The reality is that until we actually try it, we will not
have any real answer about the right way to sign XRD documents and verify
trust. The solution proposed by XRD is the compromise accomplished after almost
a year of constant debates with representation and feedback coming from a
wide-range of people and communities. But all that means is that we have
something we were able to agree to put on paper. I would also defer to Will
Norris on implementation experience because has been working on a PHP library.
I don't think the current style is so out of the ordinary.
Personally, I couldn't care less as long as it is consistent.
That's where XRD history comes in. XRD is really a rewrite
of XRDS. Since XRDS had <Type> element at the <Service> level, and
XRD has a <Type> element at the <XRD> level, we decided against
using the name <Type> in <Link> to avoid confusion with existing
XRDS implementations. <URI> was always <URI> and changing it to
href doesn't make it any clearer (and beside, href is not an accurate term
here). Note that HTTP does not use href but only wraps the URI in '<>'.
<Subject> describes the XRD itself and is critical for
trust. We considered expressing <Alias> as a link but eventually decided
that its semantics are so clear and specific that a link will just make it more
difficult for implementation. This is an optimization that only makes the spec
shorter but makes consuming XRD longer and more complex. It also means you have
to parse all the links before you can even verify trust which a simple
<Subject> element offers (and enforces cardinality).
This is a good idea but one that failed to produce any
actual proposal during the XRDS-Simple discussions. If more people find it
useful, we can add it building on the HTTP Link header. So it would look
something like:
> > 1) Denormalize the Link elements. > This should also make the
microformats and CSS crowd happy, as it's I would consider this a bad thing. XRD is taking a
completely different approach than Microformats and relies on strict semantic
meanings of its links and other elements. While XRD is extremely extensible, it
would be incorrect to use Microformats within XRD, primarily because XRD is
designed to be consume exclusively by machines (but readable by developers)
unlike HTML which is primarily for people.
> This is probably the most
important bit - XRD as per the spec right While I can appreciate the desire not having to parse XML in
some cases, this is an XML document and should be parsed with an XML parser.
There is a long story behind
the need for the 'match' attribute on <Subject>, but the short version is
that it was the best compromise we found for dealing with giving host-meta a
subject. Host-meta needs a subject for trust purposes, but there is no way to
express 'a host' using URIs. What the match attribute does is express a group
of resources using a simple matching rule. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]