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

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:17 UTC