[whatwg] Micro-data/Microformats/RDFa Interoperability Requirement
Ian Hickson
ian at hixie.ch
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list