[whatwg] Micro-data/Microformats/RDFa Interoperability Requirement

Thu May 7 12:53:22 PDT 2009

On Thu, 7 May 2009, Manu Sporny wrote:
> 
> So, this argument isn't "Don't use @class at all", but rather "Don't 
> create ambiguity in @class where there is none currently."

I agree that if HTML5 re-uses vocabulary "root" terms from Microformats, 
it should either not use class="", or should do so in a way that does not 
cause existing consumers of Microformats to treat existing content in a 
way that is not compliant with HTML5.

> Not re-defining things to mean something different than the Microformats
> community has already defined should be a design requirement.

That requirement has been broken for some time, because the definitions of 
rel="license" and rel="tag" in HTML5 differ from those on the Microformats 
wiki. (The definitions in HTML5 are closer to what existing 
implementations and content rely on, though, so I don't think it violates 
the requirement to "not cause existing consumers of Microformats to treat 
existing content in a way that is not compliant with HTML5".)

> > and RDFa because any use of the "rel" attribute can do the same.
> 
> No, not /any/ use - /specific/ uses of rel, and then only if the HTML5 
> micro-data solution does something that is counter to how RDFa uses the 
> attribute or the value.

Actually as far as I can tell, it really is any use.

The RDFa specification is very confusing to me (e.g. I don't understand 
how the normative processing model is separate from the section "RDFa 
Processing in detail"), so I may be misinterpreting things, but as far as 
I can tell:

  <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
    <base href="http://example.com/"/>
    <link about="http://example.net/"
          rel="dc.author" 
          href="http://a.example.org/"/>
   ...

...will result in the following triple:

   <http://example.net/> <http://example.com/dc.author> <http://a.example.org/> .

> The most important issue with RDFa is not re-using attributes already 
> defined by XHTML1.1+RDFa without them having the exact same use in 
> HTML5. Attributes like @about, @property, @datatype, @resource, @content 
> and @typeof.

content="" is already an attribute on <meta> in HTML, and that one can't 
be changed either.

Given that HTML4 already has five of RDFa's 10 attributes (not counting 
prefix declaration mechanisms), and defines processing for these that 
conflicts with RDFa's (e.g. as described below), it's not clear to me what 
benefit there would be in completely avoiding the other five attributes if 
there was a need to use such an attribute.

For example, it would be somewhat presumptious of RDFa to prevent any 
future version of HTML from being able to use the word "resource" as an 
attribute name. What if we want to extend the forms features to have an 
XForms "datatype" compatibility layer; why should we not be able to use 
the "datatype" and "typeof" attributes?

Surely this is what namespaces were intended for.

> > Similarly, the rules for handling CURIEs in RDFa, especially in 
> > rel="", are already incompatible with HTML4 and HTML5 rules. For 
> > example, the way that "n:next" and "next" can end up being equivalent 
> > in RDFa processors despite being different per HTML rules (assuming an 
> > "n" namespace is appropriately declared).
> 
> If they end up being equivalent in RDFa, the RDFa author did so 
> explicitly when declaring the 'n' prefix to the default prefix mapping 
> and we should not second-guess the authors intentions.

My only point is that it is not compatible with HTML4 and HTML5, because 
they end up with different results in the same situation (one can treat 
two different values as the same, while the other can treat two different 
values as different).

Another example would be the following:

  <html xmlns="http://www.w3.org/1999/xhtml">
   <head about="">
    <link rel="stylesheet" href="...">
    <link rel="STYLESHEET" href="...">
    ...

...which would be treated as two different triples in an RDFa processor, 
but treated as two identical imports according to an HTML4/5 processor.

Another example would be:

  <html xmlns="http://www.w3.org/1999/xhtml">
   <head about="">
    <link rel="stylesheet alternate next" href="...">
    ...

...which in RDFa would cause the following triples to be created:

   <> <http://www.w3.org/1999/xhtml/vocab#stylesheet> <...> .
   <> <http://www.w3.org/1999/xhtml/vocab#alternate> <...> .
   <> <http://www.w3.org/1999/xhtml/vocab#next> <...> .

...but according to HTML4/5, is really only two relations (an alternativee 
stylesheet and the next document).

> > I don't think there's much that can be done about this (this isn't 
> > something that we can change HTML5 rules for; browser vendors would 
> > not accept having to resolve QNames in rel="" attributes as part of 
> > processing, for one).
> 
> This has been explained many[2] times[3] now[4], CURIEs are not QNames. 
> If you have an issue with CURIEs, please state the exact issue that you 
> have with CURIEs and don't use a false analogy.

Browser vendors would not accept having to resolve prefixes in attribute 
values as part of processing link relations.

(What's the difference between mapping to a full URI and mapping to a 
namespace,local pair? The problem with QNames in attributes is that they 
require the attribute processor to have information from the namespace 
processor, and as far as I can tell this continues to exist in RDFa.)

> > Backwards compatibility in HTML5 is primarily concerned with being 
> > compatible with legacy markup, of which there is very little when it 
> > comes to either RDFa or Microformats (especially RDFa, since there's 
> > so little XHTML content for it to be found in).
> 
> When is the cut-off date for this?

Such things are dealt with as judgement calls. If you want a date, though, 
I guess today, since we don't have data for tomorrow yet.

> I ask because the finishing touches for HTML5 aren't supposed to be done 
> until 2022

CR (when the finishing touches are done) is supposed to happen in 2012, 
not 2022. LC (when the spec is done) is supposed to be October 2009. 2022 
is the optimistic date for the test suite to be complete and 
implementations to be bug-free.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'