Re: RDFa in HTML 5

Shelley Powers wrote:
> 
>> One last point: if XHTML1 and XHTML2 were deprecated in favor of 
>> XHTML5, then /perhaps/ inside the [X]HTML 5 spec /might/ be the right 
>> place for the definition of the "one set of processing rules for all 
>> HTML family languages", but again, I am not convinced that this is 
>> going to happen.
> 
> Sam, I'm not sure that I agree with XHTML1 or 2 being deprecated in 
> favor of XHTML5. I do not believe that XHTML5 has actually been defined 
> well enough to make this so. In fact the thought of such deprecation 
> fills me with alarm. But that's not necessarily relevant to this 
> discussion.

To clarify: I didn't mean to suggest that it should be done, but rather 
to point out that as long as it isn't done, the very first "if" test in 
the series of tests that lead to the concern that Manu described fails.

> Unlike SVG and MathML, which needed a place in the document in order to 
> encourage their support in HTML by the browsers, RDFa doesn't 
> necessarily need to be handled by the browser companies. They can choose 
> to do something with the RDFa, but there isn't the necessity of support. 
> Well other than not throwing errors, and allowing the attributes to be 
> part of the DOM. They do this now, though.

I believe that these technologies should be in the spec because they 
affect the parsing logic.  If RDFa requires the parsing logic to change, 
then I would believe likewise about RDFa.  What I have seen to date is 
that RDFa deployment is proceeding without requiring any processing 
logic changes.

Meanwhile, some browsers are supporting SVG and MathML today, and is is 
not clear to me that placement in the spec will cause the one browser 
that supports neither to suddenly do so in any meaningful timeframe.

> One issue related to the DOM is the use of namespaces and CURIE. 
> Specifically how browsers handle these differently with HTML and XHTML. 
> However, if the purpose of the HTML5 document is also to address changes 
> to the DOM, then I don't see why these differences can't be handled 
> within the HTML5 document, and perhaps this is the section that _really_ 
> needs to get added to the HTML5 spec. It is really this, not RDFa that 
> underlies Ian's resistance.

It generally is not wise to infer motives on the part of others.

I haven't seen evidence that existing RDFa parsers are hampered by 
existing browser implementations -- that's not to say that such doesn't 
exist; I'm merely stating that if such exists, I am not aware of it. 
And it is my belief that HTML5 matches existing browser parsing 
implementations to a very high degree of fidelity -- and generally if 
there is a case where it differs from one browser implementation, it 
generally does so in order to match another's.

In any case, if it is true that either browsers will need to change to 
accommodate RDFa, or that HTML5 needs to change in order to accommodate 
browsers, then I would think that it would be relatively straightforward 
to identify a single test case in the form of a fragment of HTML that 
demonstrates the problem.

> I think a commitment from members of both groups is necessary before 
> anything else is done.  But a good hard look at what's really needed to 
> ensure that RDFa in HTML5 should be made before we shove yet another 
> section into a document that's already a bit bloated.

RDFa may be impossible to address without changing browsers 
implementations in a way that breaks the web.  RDFa may be trivial to 
address without requiring any changes to browsers.  Without knowing 
which of the above two matches reality, I don't believe anybody is 
willing to sign a blank check and make a commitment.  I know I certainly 
am not.

> I think that Manu's concerns are valid. I believe that answering 
> Philip's questions are important, but not the end all or be all of 
> moving forward. I'm also extremely concerned about how willing the HTML5 
> folks are to generate multiple sets of rules for processing what should 
> be the same data. This speaks an emphasis on process over data. I think 
> the most important thing to happen, first, is that the HTML5 folks agree 
> with an underlying concept: that there is one set of rules for 
> processing the data, AND that the HTML5 folks aren't necessarily the 
> best to derive those rules.

"aren't necessarily the best"... it is hard for me to imagine a testable 
assertion that allows me to even contemplate that assertion, much less 
evaluate it.  I guess that if some one or some group were to step 
forward to actually produce the "one set of rules" (to bind them all?), 
then I would agree with this statement, but to date I have not seen 
evidence that this is likely to happen.

Meanwhile, I believe that at least some of the RDFa parsers will be 
written in JavaScript and will make use of the DOMs produced by 
browsers, and as such would benefit from being informed by the knowledge 
that some people have as to the transformation that browsers today 
employ to convert a stream of bytes into a DOM.

I actually believe that it is counter-productive to agree, "first" as 
you put it, on who should participate, but would rather instead would 
suggest that we simply agree that if significant developments occur in 
this space by whomever wishes to participate, and that if these 
developments are related to the development or deployment of such markup 
in the context of HTML (be it 4, 5, or 17), that timely pointers to such 
be placed on this mailing list, if in fact that such discussions did not 
take place on this list in the first place.

> The point is, the HTML5 specification is moving forward relatively 
> quickly to Last Call. As it stands right now, I believe sections of it 
> would be harmful to RDFa/RDF. I also believe the same sections would be 
> harmful to microformats, and the web in general. But addressing these 
> concerns is only part of the equation. Perhaps the other part of the 
> equation is just coming to an agreement about whether RDFa has to be 
> specifically included in the HTML5 spec, or if there are only specific 
> aspects of RDFa that aren't unique to RDFa that need to be addressed in 
> the document. If it's the latter, than these the areas that should have 
> priority, and perhaps an overall RDFa in X/HTML document can come at a 
> later time.

The pace of HTML5 is not one I would characterize as operating with 
undue haste.  Nor is the date of Last Call fixed.  Nor is Last Call the 
last step.

Given the pace as which sections have been added and removed, I am quite 
comfortable deferring without prejudice discussions as to which sections 
should be included or split out at this time.

Independent of the question of the macro-organization of the HTML 5 
family of specifications (a term I'm using loosely and with any intent 
to define further), I do believe that understanding to what extent RDFa 
support would require a change to the existing content (and in 
particular, the existing content that captures parsing rules) is a good 
thing to be focused on right now.

And in my opinion, the best way to proceed is with tangible test cases, 
expressed as fragments of markup.  I'm pleased to see that a number of 
people are now proceeding in that direction.

- Sam Ruby

Received on Saturday, 23 May 2009 12:34:25 UTC