[whatwg] several messages about XML syntax and HTML5

[Sam Ruby]

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