It’s just data

Ingrates

Martin Atkins: it is impossible to use Yadis in this way while having a conforming HTML 5 document. The current ethos for HTML 5 seems to be to remove any mechanism by which it can be extended in any way without going through the HTML working group and changing the core spec.

Just because YADIS didn’t have the foresight to use the officially sanctioned way to embed custom non-visible data is no reason to complain.


You mean the new way that, for all its awesomeness (that’s not sarcasm) was not around two weeks ago and would require everyone writing HTML4 and XHTML1/2 to write invalid HTML (if they were to use this solution)? ;)

Custom data should very well follow the dataset; signaling an OpenID endpoint seems like the textbook definition of a related resource to me.

Posted by Jesper at

Further: 3.4.7 ("Embedding custom non-visible data"): “User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values.”

3.7.4 ("The link element"): “The link element allows authors to link their document to other resources.”

Posted by Jesper at

Yeah, this is not at all a problem that the custom data thingie is solving. I think this should be a rel attribute value for the link element, though maybe we should allow custom values for http-equiv too.

Are experimental HTTP headers conforming to use, by the way?

Posted by Anne van Kesteren at

Also note that his http-equiv usage is not conforming per HTML4 either http://www.w3.org/TR/html401/struct/global.html#adef-http-equiv because he expects the client to handle it rather than the server. (http-equiv was basically never implemented as HTML4 meant it to be implemented.)

Posted by Anne van Kesteren at

Calling them ingrates seems a bit harsh; that blog entry seems like a reasonable comment, and the WG doesn’t automatically deserve the gratitude of potential users, to the point where it and its processes can’t be questioned.

Posted by Mark Nottingham at

I read a pretty big <sarcasm> tag round Sam’s post, but seems from comments that Jesper and Mark don’t? That said, faking pseudo HTTP headers is a pretty rubbishy way of doing it, as is a single magic prefix.

Posted by anonymous at

I’m hoping Sam was sarcastic.

Posted by Jesper at

Whether Sam’s sarcastic or not, it does seem a bit weird for a specification to require the use of a non-standard HTTP header embedded in HTML to work. Shouldn’t a new rel value for the link element be registered with IANA instead?

Posted by Asbjørn Ulsberg at

All this debate about MNot’s momentous “whoosh” moment is detracting from Sam’s original point, which is “look everyone, I’ve found somebody new through whom I can channel my passive-aggressive discontent with the WHATWG not prioritizing my pet issues to my satisfaction.”  Sadly for Sam, the original claim was half-bogus and the other half will be handled similarly.  But practical solutions don’t make for good blogwhines.  I’m sure Sam will be posting an update any day now, no doubt to complain about the WHATWG not prioritizing the <whine> tag.

Posted by Mark at

Ah - I haven’t been tracking who’s on what side of the train wreck that is HTML5, so the sarcasm (if that’s what it was) was too subtle to register.

Good to see that MarkP still has his innate charm and level-headedness.

Posted by Mark Nottingham at

Asbjørn: the YADIS specification does not require the use of a meta tag to work.  The meta tag is only checked if “X-XRDS-Location” was not present in the HTTP response headers and the response content type was not application/xrds+xml.

The meta tag is really a last resort in cases where you don’t have enough control over the server to implement one of the other methods.  Using content negotiation to serve the XRDS directly is the most desirable option, since it results in one fewer round trip than the others.

Posted by James Henstridge at

I understand that, James, but how many have access to modifying the HTTP headers of their web server? And even if they do, shouldn’t the header be standardized and thus not have an ‘X-’ prefix? Isn’t a <link type="application/xrds+xml" rel="whatever" href="yadis-document.xrds" /> (where whatever is the value registered with IANA) better?

Posted by Asbjørn Ulsberg at

Asbjørn: not having been involved in the specification of YADIS/XRDS discovery, I can’t be certain why those decisions were made.  The most likely candidate is that it was an evolving specification.

They probably chose <meta http-equiv> because it was intended to be equivalent to the HTTP header.  As for the “X-” prefix, perhaps deployment reached a stage where changing the header was impractical – that’s what happened with `application/x-bittorrent` (this is a problem with non-namespaced identifiers where registration isn’t required).

Posted by James Henstridge at

Not to mention application/x-www-form-urlencoded.

Posted by Sam Ruby at

Add your comment