- From: Sam Ruby <rubys@intertwingly.net>
- Date: Fri, 08 Dec 2006 09:05:23 -0500
Ian Hickson wrote: > On Thu, 7 Dec 2006, Sam Ruby wrote: >>> They were made around the same time (Trackback was invented first). My >>> point was just that Trackback is not a good example of why you need >>> more attributes in HTML, since there are equivalent technologies that >>> do it with existing markup and no loss of detail. >> I disagree. The pingback specification does NOT do exactly what the >> trackback specification does. >> >> Pingback discovery works for any media type, does not deal with any >> granularity smaller than a URL. >> >> Trackback discovery is limited to (X)HTML, but can deal with multiple >> entries on a single page. Here's an example: >> >> http://scott.userland.com/2005/11/09.html > > Granted, but that doesn't change the point being made here. It kinda does. If one has a single non-presentational relationship that one wishes to associate with a web page AND one has control over the HTTP headers that are sent with said web page (e.g., because your blogging software is written in PHP), then an HTTP header is a viable option. If, however, one wants to associate a small set of triples (subject-uri, relationship, predicate-uri) OR the only means that you have available for publishing your web site is FTP, then embedding such non-presentational data inside the web page itself becomes desirable. By itself, it clearly is not a slam dunk. Not even close. It is but an indicator, however small, that there is a desire for a cleanly architected extensibility mechanism defined for non-presentational (i.e., semantic) data. There may be another force in play here too. There will be a desire that one can serialize all DOMs in a way that can round trip. The discussion about putting tables inside of paragraphs puzzles me because I can't imagine why anybody would want to do that, or even what it would mean; but there may be valid use cases where serializing a valid DOM and parsing it using HTML5 rules produces a different DOM. If so, that would be sub-optimal. Past attempts to address this (XHTML1.x then XHTML2) clearly didn't strike the right balance between backwards compatibility and architected extensibility. That doesn't mean that it isn't possible, it just means that it wasn't a goal of those teams, and therefore wasn't attempted. I certainly don't expect any of the words above to elicit a "Eureka!" response. But I hope that this idea can be allowed to, as Robert put it, marinate. - Sam Ruby
Received on Friday, 8 December 2006 06:05:23 UTC