Re: ISSUE-41: Facebook open graph protocol

On Apr 22, 2010, at 2:00 PM, Sam Ruby wrote:

> On 04/22/2010 03:31 PM, Maciej Stachowiak wrote:
>> If their use of xmlns attributes is limited to RDFa, and they don't  
>> use
>> any namespaced elements or attributes other than xmlns:, then I think
>> their use is covered by the HTML+RDFa specification:
> A few questions:

Here's my best attempts to answer based on my knowledge of HTML+RDFa:

> 1) is the combination of HTML+RDFa plus Open Graph Protocol a  
> "vendor-neutral extensions" permitted by the current draft of the  
> HTML5 specification[1]?

I don't know, and I'm not sure if that question is relevant. HTML+RDFa  
is a "vendor-neutral extension" permitted by the current HTML5 draft.  
Open Graph Protocol, as I understand it, makes use of an extension  
point provided by HTML+RDFa (the ability to embed RDF vocabularies),  
therefore the applicable standard for Open Graph Protocol is whatever  
HTML+RDFa requires for vocabularies that use its extension points.

> 2) I don't believe that HTML+RDFa changes any parsing rules, but  
> does change conformance rules.
> 2a) Can anybody confirm the above?

Correct. This section summarizes UA conformance for HTML+RDFa: < 

> 2b) If so, conforming RDFa will be parsed into a DOM differently  
> based on the MIME type.  Does the RDFa draft make this clear?

The HTML+RDFa draft makes clear that it operates on the DOM level. But  
as far as I can tell it does not highlight the fact that xmlns:*  
attributes will produce different DOMs in text/html and application/ 
xhtml+xml. A while ago I filed this bug, which is a consequence of not  
explaining the DOM difference: < 
 >. I don't believe there is any bug directly asking for the HTML+RDFa  
spec to highlight the difference. I encourage you to file one if you  
think it's important.

RDFa Core 1.1 introduces @prefix as a way to binding CURI prefixes,  
and deprecates xmlns:* attributes. HTML+RDFa is going to get updated  
to be based on RDFa Core 1.1. This issue may get addressed as part of  
the update. For RDFa Core 1.1 changes, see here and scroll down: < 

> 3) Does this affect the Polyglot spec?

That depends on the goals of the Polyglot spec. If the Polyglot spec's  
goal is to only allow documents that produce an identical DOM, then  
the consequence would be that polyglot documents can't use RDFa 1.0.  
However, they could use RDFa 1.1 with @profile instead of @xmlns:*.

However, drawing a hard line on DOM differences would lead to  
disallowing xml:lang, which might not be desirable. If the polyglot  
spec allows exceptions, then Polyglot could allow RDFa 1.0 constructs,  
if that seems like a sufficiently important use case.

> 4) The current w3c validator declares this markup to be in error 
> [2].  Is somebody planning on updating the validator to handle RDFa?

I don't know what the validator team's plans are. Note that HTML5  
doesn't require validators to support any particular set of  
extensions. It's up to the maintainers of any given validator to  
decide which they consider to be "applicable specifications". I would  
hope that the team offers a profile including RDFa as at  
least one validation option, whether or not it is the default.


Received on Friday, 23 April 2010 00:38:55 UTC