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

[Ian Hickson]

On Sat, 9 May 2009, Manu Sporny wrote:
> > 
> > For rel-license, the HTML5 spec defines the value to apply to the 
> > content and not the page as a whole. This is a recent change to match 
> > actual practice and I will be posting about this shortly.
> 
> Hmm, yes - after re-reading the definitions, they do differ... 
> especially in how the hAudio Microformat uses rel="license". I find the 
> HTML5 one to be very problematic. Microformats rel="license" is better, 
> and the RDFa use of rel="license" is even better (I can go into the 
> reasoning if those on the list are curious).

The definition in HTML5 is just a description of how it's used in 
practice. It's not what I'd design if I had a choice. However, there's not 
much point defining something that doesn't match the reality of the 
situation.


> For example, in HTML5, how do you express 20 items on a page, each with 
> separate licenses? How do you differentiate a page that has 3 primary 
> topics, each with a separate license?

You can't, currently. Can you provide a sample of such a page?


> In short - what's the purpose of rel="license" if a machine can't use it 
> to help the person browsing identify important sections of a page?

rel=license as it stands today is useful only (as far as I can tell) for 
people searching the Web for pages whose main content (e.g. the photo on a 
Flickr page, the text of a blog post on a blog post's permalink, etc) is 
licensed under a particular license identified by URI.


> Afterall, it's only machine readable, isn't it? What's the sense in 
> having rel="license" if a machine can't be sure of the section of the 
> page to which it applies?

Generally speaking, search engines are pretty competent at distinguishing 
the page's main content from ancillary content such as style sheets or 
navigation links.


> More importantly, if you see this as an issue, why don't you see the 
> semantic difference between rel="alternate"[3] in HTML4 and 
> rel="alternate"[4] in HTML5 as being an issue? That case is even worse, 
> exactly the same string - entirely different semantics.

HTML5's definition, again, matches what actual implementations and author 
usage is. HTML5 isn't trying to be compatible with HTML4, it's trying to 
be compatible with legacy content.


> > You would have to ask them. I tend not to argue with implementor 
> > feedback. If they tell me they won't do something, I don't tell them 
> > to do it.
> 
> I would expect the primary editor for a web specification to understand 
> the reason that every single one of their implementors refuse to 
> implement a technique that they use elsewhere in their products.

I believe I do, but I wouldn't want to put words in their mouth on such 
controversial topics.


> I'd love to ask eacho of them why it is perceived as difficult and 
> discuss possible solutions. A public e-mail would be best so that we can 
> discuss on this list, but a private e-mail would be fine as well. So 
> please, if your organization has decided to not resolve prefixes in 
> attribute values, please send me an e-mail.
> 
> After two weeks, I'll check back in with the mailing list to report on 
> the number of responses I received and a summary of the reasoning 
> (anonymized, of course) for the benefit of this community.

Did you receive any responses?

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

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

[Ben Adida]

Julian wrote:

You are aware of MNot's "Web Linking" draft
(),
and the fact that it seems to enjoy support from the TAG?


Julian, you continue to bring this up as if we hadn't already discussed 
this: there are significant differences of opinion with mnot on whether 
his interpretation of @rel values is correct in prior HTML versions, and 
there are a number of folks who disagree (not just us in RDFa), 
including at least two RECs (RDFa and GRDDL).


The point is: if you assume that @rel="foo" always means the same thing, 
then many folks believe you're already violating the HTML spec, which 
specifically uses @profile to modulate the meaning of @rel, and 
sometimes via another level of indirection.


-Ben

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

[Manu Sporny]

Julian Reschke wrote:
> Manu Sporny wrote:
>> ...
>> The second is that you are assuming that @rel/@rev reserved attribute
>> values are the same for all XML and non-XML family languages - they
>> aren't. Reserved words such as "next" and "prev" can be defined per
>> language - or, none can be defined... it's up to the language adopting
>> RDFa to define those values. For a list of the current values, you can
>> see:
>> ...
> 
> They currently can be defined per language, but that doesn't make it a
> good idea.

I agree in principle, but practicality overrode that principle in the
RDFa Task Force. The reason they're defined per language is because:

1. We were specifically working on RDF in XHTML and did not have the
authority to define them for all languages.
2. We also couldn't base a solution on another draft document.
3. Even if we could do all of this, getting each HTML-family work group
to agree on a set of common @rel types would be nearly impossible for
our small group to accomplish while working on RDF in XHTML.

> You are aware of MNot's "Web Linking" draft
> (),
> and the fact that it seems to enjoy support from the TAG?

Thanks for pointing it out, I wasn't aware of that draft :). RDFa can be
used in non-web-languages, so we shouldn't go overboard by saying that
the Web Linking draft should apply for all languages that use RDFa.

I agree that it would be good for web languages to standardize around
that draft for LinkTypes... specifically for reserved @rel/@rev values
in RDFa for HTML family languages. I've raised the issue[1] with the
RDFa Task Force... we'll discuss further on that list.

-- manu

[1]http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009May/0054.html

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/

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

[Manu Sporny]

Ian Hickson wrote:
> On Thu, 7 May 2009, Manu Sporny wrote:
>> That's certainly not what the WHATWG blog stated just 20 days ago for
>> rel="license" [...]
> 
> The WHATWG blog is an open platform on which anyone can post, and content 
> is not vetted for correctness. Mark can sometimes make mistakes. Feel free 
> to post a correction. :-)

Well, the problem is that I don't know who to correct - you or Mark.
It's unclear to me if it's the spec that needs correcting or the blog post?

> For rel-license, the HTML5 spec defines the value to apply to the content 
> and not the page as a whole. This is a recent change to match actual 
> practice and I will be posting about this shortly.

Hmm, yes - after re-reading the definitions, they do differ...
especially in how the hAudio Microformat uses rel="license". I find the
HTML5 one to be very problematic. Microformats rel="license" is better,
and the RDFa use of rel="license" is even better (I can go into the
reasoning if those on the list are curious).

For example, in HTML5, how do you express 20 items on a page, each with
separate licenses? How do you differentiate a page that has 3 primary
topics, each with a separate license?

In short - what's the purpose of rel="license" if a machine can't use it
to help the person browsing identify important sections of a page?
Afterall, it's only machine readable, isn't it? What's the sense in
having rel="license" if a machine can't be sure of the section of the
page to which it applies?

>>> Surely this is what namespaces were intended for.
>> Uhh, what sort of namespaces are we talking about here? xmlns-style, 
>> namespaces?
> 
> The idea of XML Namespaces was to allow people to extend vocabularies
> with a new features without clashing with older features by putting the 
> new names in new namespaces. It seems odd that RDFa, a W3C technology for 
> an XML vocabulary, didn't use namespaces to do it.

As you are aware, the RDF in XHTML 1.1 Task Force was created to figure
out a way to express RDF via XHTML. The standard mechanism for extending
XHTML is XHTML Modularization[1]. From the XHTML modularization spec:

"""
This modularization provides a means for subsetting and extending
XHTML... this specification is intended for use by language designers as
they construct new XHTML Family Markup Languages.
"""

We used the standard mechanism, specifically designed to extend XHTML
vocabularies, approved by the XHTML working group, the W3C TAG and a
number of other W3C and public web groups, to extend the language.

Had we been tasked with expressing RDF in XML, we would have called it
RDF/XML[2]... :)

> 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).
>> It is only not compatible with HTML5 if this community chooses for it to 
>> not be compatible with HTML5. Do you agree or disagree that we shouldn't 
>> second guess the authors intentions if they go out of their way to 
>> declare a mapping for 'n'?
> 
> I don't think that's a relevant question. My point is that it is possible 
> in RDFa to put two strings that have different semantics in HTML4 and yet 
> have them have the same semantics in RDFa. This means RDFa is not 
> compatible with HTML4.

Of course it's relevant - the whole reason there are two strings with
the same semantics, in your rather contrived example, is because the
author went out of their way to make the statement. This doesn't happen
by accident - the web page author intended it to happen.

More importantly - you've just made the same statement twice in RDFa and
once in HTML4. I can't think of a single technically significant
negative repercussion for generating a duplicate triple in a corner
case. Why does one duplicated triple in a contrived example mean that
the entirety of RDFa isn't compatible with HTML4?

More importantly, if you see this as an issue, why don't you see the
semantic difference between rel="alternate"[3] in HTML4 and
rel="alternate"[4] in HTML5 as being an issue? That case is even worse,
exactly the same string - entirely different semantics.

If HTML4 validation is a concern, there's even a preliminary HTML4+RDFa
DTD that is available:

http://www.w3.org/MarkUp/DTD/html4-rdfa-1.dtd

I do get your point - but why should we be concerned about it?

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

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

[Julian Reschke]

Manu Sporny wrote:

...
The second is that you are assuming that @rel/@rev reserved attribute
values are the same for all XML and non-XML family languages - they
aren't. Reserved words such as "next" and "prev" can be defined per
language - or, none can be defined... it's up to the language adopting
RDFa to define those values. For a list of the current values, you can see:
...


They currently can be defined per language, but that doesn't make it a 
good idea.


You are aware of MNot's "Web Linking" draft 
(), 
and the fact that it seems to enjoy support from the TAG?


BR, Julian

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

[Ian Hickson]

On Thu, 7 May 2009, Manu Sporny wrote:
> 
> That's certainly not what the WHATWG blog stated just 20 days ago for
> rel="license" [...]

The WHATWG blog is an open platform on which anyone can post, and content 
is not vetted for correctness. Mark can sometimes make mistakes. Feel free 
to post a correction. :-)


> and the spec doesn't seem to clearly outline the difference in 
> definition either (at least, that's not my reading of the spec):
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-license
> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-tag

Actually I just looked at the rel-tag faq and found that it disagrees with 
what Tantek had told me, so (assuming the faq is normative or that the 
rel-tag spec does mention this somewhere that I didn't find) the specs do 
match here.

For rel-license, the HTML5 spec defines the value to apply to the content 
and not the page as a whole. This is a recent change to match actual 
practice and I will be posting about this shortly.


> > 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:
> > 
> >   http://www.w3.org/1999/xhtml";>
> >
> > http://example.com/"/>
> > http://example.net/";
> >   rel="dc.author" 
> >   href="http://a.example.org/"/>
> >...
> > 
> > ...will result in the following triple:
> > 
> >  
> >  .
> 
> Two corrections:
> 
> The first is that an RDFa processor would not generate this triple.

My apologies, I misinterpreted 5.4.4. Use of CURIEs in Specific Attributes 
to mean that rel="" was a relative-uri-or-curie attribute. (5.4.4. Use of 
CURIEs in Specific Attributes says it's "link-type-or-curie", but 5.4.3. 
General Use of CURIEs in Attributes doesn't list that as a possibility and 
at the end says that rel="" is an exception only insofar as it supports 
specific link types as well, which I interpreted differently.)


> > 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?
> 
> As long as their legacy nature was preserved, and those uses didn't 
> create ambiguity in RDFa processors and semantic equivalence was 
> ensured, I don't see why they shouldn't be re-used.

Ah, ok. If such attributes are re-used, I suppose that it should be 
possible to make sure that it is possible to re-use them in a way that 
doesn't conflict with RDFa (e.g. by triggering the non-curie-non-uri 
behaviour for property="" or by having authors who want RDFa compatibility 
use xmlns:http="http:" declarations or some such).

Noted.


> > Surely this is what namespaces were intended for.
> 
> Uhh, what sort of namespaces are we talking about here? xmlns-style, 
> namespaces?

The idea of XML Namespaces was to allow people to extend vocabularies
with a new features without clashing with older features by putting the 
new names in new namespaces. It seems odd that RDFa, a W3C technology for 
an XML vocabulary, didn't use namespaces to do it.


> >>> 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).
> 
> It is only not compatible with HTML5 if this community chooses for it to 
> not be compatible with HTML5. Do you agree or disagree that we shouldn't 
> second guess the authors intentions if they go out of their way to 
> declare a mapping for 'n'?

I don't think that's a relevant question. My point is that it is possible 
in RDFa to put two strings that have different semantics in HTML4 and yet 
have them have the same semantics in RDFa. This means RDFa is not 
compatible with HTML4.


> > Another example would be:
> > 
> >   http://www.w3.org/1999/xhtml";>
> >
> > 
> > ...
> > 
> > ...which in RDFa would cause the following triples to be created:
> > 
> ><>  <...> .
> ><>  <...> .

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

[Manu Sporny]

Ian Hickson wrote:
> 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.

Good, there's agreement there, then. :)

>> 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".)

That's certainly not what the WHATWG blog stated just 20 days ago for
rel="license":

http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-license
http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-tag

and the spec doesn't seem to clearly outline the difference in
definition either (at least, that's not my reading of the spec):

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-license
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-tag

Am I looking at the wrong spec? How can the definitions of rel="license"
and rel="tag" be different when Mark Pilgrim has stated very clearly
that they were standardized in the Microformats community and the HTML5
spec makes no mention of any sort of difference in definition from HTML5
and Microformats?

>>> 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.

No it isn't, more below. :)

> 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:
> 
>   http://www.w3.org/1999/xhtml";>
>
> http://example.com/"/>
> http://example.net/";
>   rel="dc.author" 
>   href="http://a.example.org/"/>
>...
> 
> ...will result in the following triple:
> 
>  
>  .

Two corrections:

The first is that an RDFa processor would not generate this triple. It
wouldn't know what "dc.author" meant. As a general design principle,
RDFa ignores all values it doesn't know anything about. The processor
would detect the subject being set via the @about, then it would go
searching for a known CURIE value or (in XHTML1.1+RDFa) a known
@rel/@rev reserved attribute value (such as "next", "stylesheet", etc.).
Since "dc.author" is neither a known CURIE value or a known reserved
word, it would exit the LINK element without creating any triples.

The second is that you are assuming that @rel/@rev reserved attribute
values are the same for all XML and non-XML family languages - they
aren't. Reserved words such as "next" and "prev" can be defined per
language - or, none can be defined... it's up to the language adopting
RDFa to define those values. For a list of the current values, you can see:

http://www.w3.org/TR/rdfa-syntax/#relValues

>> 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.
> 
> 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.

Note that I didn't say "completely avoid" attributes... I said "re-using
attributes already defined by XHTML1.1+RDFa without them having the
exact same use in HTML5". At this point, I don't see any conflict
between XHTML1.1+RDFa and HTML5.

I was asking for semantic equivalence when adopting attributes, not
complete avoidance.

> 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 t

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

[Ian Hickson]

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:

  http://www.w3.org/1999/xhtml";>
   
http://example.com/"/>
http://example.net/";
  rel="dc.author" 
  href="http://a.example.org/"/>
   ...

...will result in the following triple:

      
.


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

  http://www.w3.org/1999/xhtml";>
   


...

...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:

  http://www.w3.org/1999/xhtml";>
   

...

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

   <>  <...> .
   <>  <...> .
   <>  <...> .

...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

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

[Manu Sporny]

Ian Hickson wrote:
>> - Not triggering output in a Microformats/RDFa parser as a side-effect
>>   of WHATWG micro-data markup.
>> - Not creating an environment where WHATWG micro-data markup breaks or
>>   eliminates Microformats/RDFa markup.
> 
> This isn't possible. 

Things that are impossible just take longer, right :)

In all seriousness, I think there was a mis-communication here, the
things that I'm thinking about are possible, I'll elaborate and further
clarify below.

> Even a regular HTML5 document with no microdata 
> annotations that links in a style sheet ends up triggering output in 
> Microformats and RDFa parsers 

This is fine and is what legacy markup does in the same RDFa processor
that purposefully doesn't throw an error when processing a
non-XHTML1.1+RDFa document. By design, RDFa generates triples for
certain rel/rev values that were semantic terms in HTML4.

> -- Microformats because any use of 'class' 
> can clash with a Microformats class name, 

Yes, and unintended clashes with Microformats is fine as long as
whatever micro-data solution that this community adopts doesn't do
something like:

Rupert Giles

and then define different values for 'fn' inside an 'hcard' that
conflict with what the Microformats community has stated that they mean.
Since Microformats don't use named scopes for most of their vocabulary
terms, it's far easier to clash with those terms than it is to clash
with the RDFa terms.

The RDFa community was very careful to not negatively impact existing
Microformats markup. We purposefully did not re-use @class because in
the RDFa designs that did re-use it, it caused a number of
clashes/issues. Similarly, we did not re-use @id because authors were
already using it in a way that did not mesh well with semantic markup
concepts.

So, this argument isn't "Don't use @class at all", but rather "Don't
create ambiguity in @class where there is none currently."

Not re-defining things to mean something different than the Microformats
community has already defined should be a design requirement. For
example, don't create an ambiguous situation where a Microformats parser
would parse an vcard/FN and understand that this is a hCard Microformat
with a "Formatted Name" of "Rupert Giles" and a HTML5 micro-data parser
would do the same and determine that you're talking about something that
is semantically different.

> 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. Really, the @rel values are only defined for
XHTML1.1, so this is technically less of a concern for RDFa than it is
for Microformats.

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.

> It's also not clear to me what RDFa's position in text/html is. As I 
> understand it, RDFa only applies to XHTML. Thus it seems that HTML5 has 
> already broken compatibility with RDFa, since it requires processors to 
> handle text/html content in a non-XML manner.

No exactly, the processing rules for RDFa are more-or-less XML-agnostic
(by design) and can be made completely XML-agnostic with a minimal set
of known changes.

There is this lingering issue of xmlns in HTML5, but even if WHATWG
removes xmlns entirely from HTML5 (which we don't want you to do), there
is still the @prefix alternative[1] for RDFa.

RDFa also uses @rev extensively, so removing that value from HTML5 has
some fairly strong negative consequences for RDFa, which is why we would
prefer that it not be removed.

> 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. Unless I'm
missing something, "n:next" and "next" cannot accidentally end up being
equivalent - they cannot become equivalent due to language ambiguity and
they cannot become equivalent due to a bug in the current RDFa
processing rules.

We were very careful about not accidentally creating the ambiguity you
describe. So, I'm asserting that the rules for handling CURIEs in RDFa
are not incompatible with HTML4 and HTML5 rules. Do you have any other
examples that counter this point? Please either confirm or deny so that
I can make note of it on the RDFa wiki.

In any case, this discussion is about HTML5 /not/ creating ambiguity for
values that Microformats/RDFa uses /if/ a different micro-data soluti

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

[Ian Hickson]

On Tue, 5 May 2009, Manu Sporny wrote:
> 
> There should be a requirement, as Microformats and XHTML1.1+RDFa have 
> required, that a potential solution to this issue should be compatible 
> with both the Microformats and RDFa approaches. This would mean, at a 
> high-level:
> 
> - Not creating ambiguous cases for parser writers.

Noted, thanks.


> - Not triggering output in a Microformats/RDFa parser as a side-effect
>   of WHATWG micro-data markup.
> - Not creating an environment where WHATWG micro-data markup breaks or
>   eliminates Microformats/RDFa markup.

This isn't possible. Even a regular HTML5 document with no microdata 
annotations that links in a style sheet ends up triggering output in 
Microformats and RDFa parsers -- Microformats because any use of 'class' 
can clash with a Microformats class name, and RDFa because any use of the 
"rel" attribute can do the same.

So I'm not sure really how to handle such a requirement.

It's also not clear to me what RDFa's position in text/html is. As I 
understand it, RDFa only applies to XHTML. Thus it seems that HTML5 has 
already broken compatibility with RDFa, since it requires processors to 
handle text/html content in a non-XML manner.

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).

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).


> I think these are implied since HTML5 has gone to great lengths to
> provide backward compatibility.

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).

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

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

[Manu Sporny]

bcc: Public RDFa Task Force mailing list (but not speaking as a member)

Thinking out loud...

It seems as though there is potential here, based on the recent IRC
conversations about the topic[1] and the use cases[2] posted by Ian,
that WHATWG's use cases/requirements, and therefore solution, could
diverge from both the Microformats community as well as the RDFa
community use cases/requirements/solution.

There should be a requirement, as Microformats and XHTML1.1+RDFa have
required, that a potential solution to this issue should be compatible
with both the Microformats and RDFa approaches. This would mean, at a
high-level:

- Not creating ambiguous cases for parser writers.
- Not triggering output in a Microformats/RDFa parser as a side-effect
  of WHATWG micro-data markup.
- Not creating an environment where WHATWG micro-data markup breaks or
  eliminates Microformats/RDFa markup.

I think these are implied since HTML5 has gone to great lengths to
provide backward compatibility. However, since I'm not clear on the
details of how this community operates, I thought it better to be
explicit about the requirement.

-- manu

[1]http://krijnhoetmer.nl/irc-logs/whatwg/20090430#l-693
[2]http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019374.html

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/