Re: RDFa in HTML 5

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

The one browser company that implements neither has expressed 
reservations about XHTML. By providing for SVG and MathML in HTML, we 
remove one concern. True, may not make a difference -- but at least one 
excuse is removed.

>
>> 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 rather thought it was wise to do so, it's been happening so much the 
last few days.

>
> 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.
>
Good point, and perhaps a much better approach than trying to throw 
together formal documentation as first step.
>> 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.
>
Another good point, if we're mainly concerned about breaking today's web.

>> 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 think one can presume that programing logic is the same regardless of 
whether it is implemented in PHP, Python, or JavaScript. If so, then one 
can presume that JavaScript developers can read the same specs as 
developers in other programming languages. The English used is 
relatively simple. Not too many big words.

Frankly, I've not seen a demand for JavaScript engines to consume 
in-page RDFa and produce triples...in-page. But I won't deny there might 
not be interest.  So, yes, it will be interested to test all of this out.

> 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.
>
I think I agree.

>> 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.
>
Now that, I can agree with totally.
> 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.
>

And agree with that, too.  So, fun game next week: let's all break stuff.

Shelley

Received on Saturday, 23 May 2009 14:02:12 UTC