Re: HTML+RDFa Heartbeat Draft publishing request

Lachlan Hunt wrote:
>>> Some examples of such independent vocabularies include RDFa, ITS and
>>> Ruby. Note in particular that these are examples, and not an exclusive
>>> list of the only ones we may choose to support.
>>
>> I don't think anybody claimed that.
> 
> It has been claimed in the past by some people in arguing that Microdata 
> was out of scope.

Yes, Microdata is out-of-scope just as RDFa is. Microdata and RDFa are 
examples of extension vocabularies the WG shouldn't define but for which 
it should consider defining an *extension point* for.

> ...
>> Let's get back to what the charter says:
>>
>> "The HTML WG is encouraged to provide a mechanism to permit ..."
>>
>> So this is about an extension *mechanism*, not a specific extension.
> 
> If you want to look at it that way, then the mechanism to do so is by 
> adding native support for the vocabularies in the HTML serialisation. It 
> doesn't say anywhere that it needs to a generic mechanism.
> ...

Adding the vocabulary doesn't define an extension mechanism, it's 
avoiding to do so by extending the core.

>> Neither RDFa, nor Microdata are extension mechanisms that allow adding
>> "independently developed vocabularies" to HTML. They operate on a
>> different level.
> 
> Yes they are.  While I agree they are at a different level from things 
> like Ruby and ITS, vocabularies for both Microdata and RDFa can be 
> developed independently.  That's the whole point of them.  Take, for 
> instance, the Creative Commons vocabulary for RDFa, or any of the 
> Microformat vocabularies that have been mapped to Microdata.  In this 
> sence, RDFa is both an independent vocabulary, and a mechanism for 
> including other independent vocabularies.

*HOW* is RDFa (or Microdata) an extension mechanism that allows adding 
the RDFa vocabulary?

>>> And trying to twist the language of the charter, as Larry did, to
>>> suggest that we are only permitted to develop one mechanism that works
>>> for all of the independent vocabularies is counter productive as it
>>> only serves to limit the choices available to the group, which is
>>> clearly the opposite meaning intended by the parts granting the group
>>> such freedom of choice.
>>
>> I'd be happy if we had plans/ideas for multiple of these mechanisms for
>> text/html. So far we have none (unless you count the general statement
>> about extensions being possible as a concrete mechanism).
> 
> You agreed above that "Native support in the HTML serialisation" was 
> such a mechanism, which is exactly the technique used to incorporate the 
> Microdata, Ruby and the RDFa proposal.  So how can you suddenly claim we 

It appears that we understand "native support in the HTML serialization" 
differently. To me it is something we'd add to the text/html 
serialization that allows adding independently developed vocabularies 
*without touching the spec*.

Ruby, SVG and MathML have been added *directly* to the language; they 
required modifying the actual spec. This is *not* an example of what the 
charter is asking for (if this would have been the intent, it would have 
simply asked to consider *including* these vocabularies, right?).

Microdata and RDFa are not part of HTML5, and the extension point they 
currently use is:

"When vendor-neutral extensions to this specification are needed, either 
this specification can be updated accordingly, or an extension 
specification can be written that overrides the requirements in this 
specification. When someone applying this specification to their 
activities decides that they will recognise the requirements of such an 
extension specification, it becomes an applicable specification for the 
purposes of conformance requirements in this specification."

This *is* an extension point used *for* RDFa or Microdata, but RDFa and 
Microdata aren't the extension point.

> have no such mechanisms?  You seem to be implying that we need a generic 
> mechanism, รก la namespaces in HTML, but as explained above, that is not 
> necessarily what the charter calls for, and, as a practical matter, is 
> not even a viable solution.

Namespaces for HTML indeed would be an extension point that qualifies.

But this is a totally separate discussion.

The question was: are RDFa or Microdata part of our charter because they 
provide the extension mechanism the charter is asking for? As far as I 
can tell, the answer to that very clearly is *no*.

And finally, as I said before: just because I agree with Larry on what 
the charter says doesn't necessarily mean that I would object to future 
work on RDFa-in-HTML or Microdata. All I'm saying is that quoting the 
charter as *supporting* that is incorrect.


Best regards, Julian

Received on Wednesday, 13 January 2010 14:55:35 UTC