[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Feedback on the XRD specification draft
I think that the purpose of the Link element in XRD is different enough from the presentational purpose of the Link elements in Atom and HTML to argue against re-use. They mean different things so they are different
things : XRD links are meant to describe links from the described resource to another resource, HTML/ATOM links are meant to describe links to a presentable resource addressable by a URL.
That said, I also think DeWitt has raised some very good points.
I have brought up several times the possibility of re-using XLink and the general consensus has always been it was something to look into but not re-use. Per the WC3's XLink TR (
http://www.w3.org/TR/xlink ) XLink "allows
elements to be inserted into XML documents in order to create and describe links between resources. It uses XML syntax to create structures that can describe links similar to the simple unidirectional hyperlinks of today's
HTML, as well as more sophisticated links."
Question is...can it be made to work with the XRD model? I think it can but it would mean changing some things (for instance having one link per connection between two resources, not one link per connection type -
i.e. links would become 1-1 instead of the current 1-n). I would need to look at it again after reviewing current model and I'd welcome thoughts from those more versed in the XRD model like Eran. I'm on the fringes of the XRI TC though, being more focused
on XDI, so if XLink has already been discussed recently please just refer me to the mail message thread, wiki page, etc.
=Bill.Barnhill
From: Eran Hammer-Lahav [eran@hueniverse.com] Sent: Saturday, August 22, 2009 4:19 PM To: XRI TC Subject: [xri] FW: Feedback on the XRD specification draft
From: Eran Hammer-Lahav
I did not mean to suggest by my comments regarding IPR and process for submitting feedback that your list of suggestions suffers from any such limitations. But like any standards body, OASIS has very clear rules about how feedback should be collected, and since that is the venue of this work, we need to respect that. Also not that feedback is welcomed at any time and my comment about an upcoming public review did not mean to put your feedback on hold. I just meant to say that we are about to seek much larger review than the internal TC review so far.
So please don’t wait with continuing to engage the TC with your comments and suggestions. It would be significantly better if you did it following the rules. Being able to actively engage the TC and have an open conversation about the proposal can never be replaced by a TC member simply forwarding your comments to another list.
I am not going to reply to the feedback below just yet. I would rather give other TC members a chance to form and express their opinions.
However, I do want to ask you a question about supporting multiple rel values (space delimited) in a single link. HTML supports that but you proposed to eliminate it. Was that intentional change to the HTML syntax?
EHL
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]