W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > September 2009

Re: Request to publish HTML+RDFa (draft 3) as FPWD

From: Sam Ruby <rubys@intertwingly.net>
Date: Tue, 22 Sep 2009 08:53:30 -0400
Message-ID: <4AB8C8CA.50604@intertwingly.net>
To: Henri Sivonen <hsivonen@iki.fi>
CC: Jonas Sicking <jonas@sicking.cc>, Julian Reschke <julian.reschke@gmx.de>, Shane McCarron <shane@aptest.com>, Maciej Stachowiak <mjs@apple.com>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
Henri Sivonen wrote:
> On Sep 22, 2009, at 11:26, Jonas Sicking wrote:
> 
>> If I understand Henris email correctly though, he's not opposing the
>> publication because of violating the "define error handling"
>> principle,
> 
> Indeed, the email where I mentioned "define error handling" and the 
> email where I said I don't support publication were two distinct emails.
> 
> The reason I cited for not supporting publication was the failure to 
> define the processing model of RDFa in terms of the output of the 
> processing models of the underlying specs. (I'm taking Shane's word for 
> it that RDFa processing isn't written from the DOM or Infoset perspective.)

I'd like to suggest that that is a means, rather than an end it itself. 
  First, I'd like to cite the following passage in the HTML5 draft, 
section 2.2:

     Conformance requirements phrased as algorithms or specific steps
     may be implemented in any manner, so long as the end result is
     equivalent. (In particular, the algorithms defined in this
     specification are intended to be easy to follow, and not intended
     to be performant.)  Conformance requirements phrased as algorithms
     or specific steps may be implemented in any manner, so long as the
     end result is equivalent. (In particular, the algorithms defined in
     this specification are intended to be easy to follow, and not
     intended to be performant.)

The HTML5 draft also specifically mentions implementations that do not 
support scripting as not requiring a DOM at all (from the same section):

     Implementations that do not support scripting (or which have their
     scripting features disabled entirely) are exempt from supporting the
     events and DOM interfaces mentioned in this specification. For the
     parts of this specification that are defined in terms of an events
     model or in terms of the DOM, such user agents must still act as if
     events and the DOM were supported.

My conclusion is that defining RDFa in HTML in terms of a DOM or an 
Infoset are but two of the possible ways of achieving the desired 
result, namely being precise as to what triples MUST be produced from a 
given input.

If the current draft doesn't contain that level of precision, that's the 
basis for one or more bug reports.  But in my opinion defining RDFa in 
terms of the underlying processing model -- while it may end up being 
the most convenient way to achieve precision or ultimately end up being 
a virtual necessity -- is not itself a fundamental requirement.

- Sam Ruby
Received on Tuesday, 22 September 2009 12:54:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 September 2009 12:54:16 GMT