Re: HTML+RDFa Heartbeat Draft publishing request

Maciej Stachowiak, Wed, 13 Jan 2010 07:48:14 -0800:
> On Jan 13, 2010, at 2:08 AM, Julian Reschke wrote:

>> I agree with Larry -- the charter *clearly* doesn't ask for RDFa or 
>> (similar extensions) to be added, but for an extension mechanism 
>> that allows to add those.

I'm not sure about the part of Larry's letter which emphasized _one_ 
mechanism. Note the words "also" and "and" - or simply the mere fact 
that several mechanism are mentioned as examples:

]] Whether this occurs through the extensibility mechanism of XML, 
whether it is also allowed in the classic HTML serialization, and 
whether it uses the DTD and Schema modularization techniques [...] [[

The weight in the charter is rather on "mechanism". And "mechanism" is 
again linked to the validity issue: Follow one or several sanctioned 
mechanisms => the document can validly be extended. Predictable 
validity is the important matter here.

Maciej:
> It's worth noting especially that we have some pre-existing 
> extensibility mechanisms, including XML namespaces in the XML 
> serialization only, class, rel and <meta>. 

Class, rel an <meta> do not - at least not in HTML4 - constitute ]]a 
mechanism to permit independently developed vocabularies […] to be 
mixed into HTML documents[[. One could say that any time we add a 
class, we in fact add semantics, but that stretches it a bit. 

But HTML4 has *a* mechanism which allows you to use @class, @rel and 
<meta> to add shared, predefined vocabularies: HTML4 profiles, were the 
spec which the @profile links to is what defines the semantics. Dublin 
Core has used that option to develop a system that probably is a 
powerful and distributed as RDFa - but for the part that DC doesn't 
define any new attributes - it doesn't define "HTML+DCa".

The charter simply asks for more such options - I believe it primarily 
asks for a mechanism to add the already existing methods - such as 
RDFa. It certainly does not ask for anything to be removed - such as 
@profile. (The Charter also mentioned DTDs - and HTML4 has DTDs ... ) 

Maciej:
> I believe that when the charter is potentially ambiguous, it should 
> be interpreted to avoid readings that lead to silly results (like 
> impossible requirements).

I don't think the charter describes an impossible extension mechanism. 

XHTML has both DTDs, Schema and namespacese. As an example, the 
XHTML+RDFa document type relies both on DTD (for adding the new 
attributes) and on namespaces, where the DTD is used to add the new 
RDFa attributes. Some has already tried to define HTML5 or HTML4.5 via 
DTD.

Julian Reschke, Wed, 13 Jan 2010 16:58:45 +0100:

> Let me clarify again: all I was saying is that both RDFa and 
> Microdata are not extension mechanisms that would fall under what the 
> charter mentions (otherwise I'd like to see how Microdata can be used 
> to include RDFa *or* ITS *or* Ruby into the language).
> 
> I do not object to work on them even though I don't believe they are 
> part of the charter. I also agree that a single extension point 
> probably isn't sufficient, and that both RDFa and Microdata *are* 
> extension points.

I think the we do have one extension "mechanism" in HTML5. The HTML5 
"mechanism" has 2 steps: (1) write a spec extension. (2) And then, in 
order to make the extension valid, somehow (how?) obtain "applicable 
specification" status [1]. (Section "2.2.2 Extensibility".)

We could compare HTML4 profiles against the HTML5 "applicable 
specification" extension approach:

HTML4 profiles, like HTML5 extensions, require someone to write a spec. 
Neither HTML4 profiles nor HTML5 extension guarantee UA support for 
whatever the profile defines. The only thing that a HTML4 profile 
guarantees is validity. The validity of HTML4 profiles does not depend, 
however, on the profile specification, but on the fact that the profile 
only permits you to use features that are already part of HTML4. (I 
will not discuss the exact purpose of @profile in HTML4 profiles in 
this round.)

An HTML5 extension, however, solely relies on becoming recognized as an 
"applicable specification". So it looks like an HTML5 extension will be 
considered invalid, until recognized as applicable. And it will 
probably not be recognized as applicable without "proof" that it 
actually "does" something = has support. So, w.r.t. validity, HTML4 
profiles and HTML5 extensions, are opposites. HTML5 is very "priestly", 
despite its editor: You must ask for blessing first ...

Both HTML4 profiles and HTML5 extensions could define specs for pretty 
much anything. RDFa, in comparison, is a focused feature. 

Julian, you previously made the point that Microdata and RDFa should 
have equal status:

> the same status with respect to document validity.

I would extend that principe to HTML4 profiles - they should also be 
equally valid in HTML5. But the question is again about the "applicable 
specification" thing. I don't think, right now, that we can guarantee 
that Microdata or RDFa will be considered an "applicable specification" 
- thus we can't guarantee that they will be equally valid. 

When even Ian wonders about validation and whether Microdata would be 
considered a "second class citizen" of HTML5 if it is not part of the 
HTML5 language directly, then we should perhaps look again at the 
option of having *mechanisms* for ensuring validity of profiles and 
extensions. 
____
[1] http://www.w3.org/mid/4B4CB436.7010209@intertwingly.net

-- 
leif halvard silli

Received on Wednesday, 13 January 2010 19:49:17 UTC