W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2013

Re: Other HTML5 feature dependencies

From: Ivan Herman <ivan@w3.org>
Date: Mon, 18 Mar 2013 14:53:49 +0100
Cc: Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>, "Michael(tm) Smith" <mike@w3.org>
Message-Id: <06E823DC-3914-4417-92B7-6D6061BAF2A7@w3.org>
To: Robin Berjon <robin@berjon.com>
Merci Robin!

Ivan

On Mar 18, 2013, at 14:40 , Robin Berjon <robin@berjon.com> wrote:

> On 18/03/2013 02:17 , Manu Sporny wrote:
>> ----------------------------------------------------------------------
>> General dependence on the HTML5 parsing algorithm.
>> 
>> We state in several places throughout the specification that the RDFa
>> processor is allowed to re-arrange the input tree based on the HTML5
>> parsing algorithm. For example, re-parenting badly nested elements,
>> closing unclosed elements, etc. This is a fairly large and complex
>> algorithm that was reverse engineered over the years to yield a set of
>> rules that are now implemented across all major browsers. The likelihood
>> of the algorithm changing in any meaningful way (other than to fix bugs)
>> is low because it would mean a fairly fundamental change to the
>> algorithm which would have to have buy-in from the majority of the major
>> browser manufacturers.
> 
> Right. Note that we might add to it (if we introduce new elements that have an impact on self-closing for instance) but I don't expect that to happen much (if at all in the 5.0 time frame, and certainly not in a big way). And we certainly won't break what we have. This is also one of the most tested parts of the spec.
> 
>> ----------------------------------------------------------------------
>> Section 3.4: Invalid XMLLiteral Values
>> 
>> """
>> An RDFa processor that transforms the XML fragment must use the Coercing
>> an HTML DOM into an infoset algorithm, as specified in the HTML5
>> specification, followed by the algorithm defined in the Serializing
>> XHTML Fragments section of the HTML5 specification.
>> """
>> 
>> The same argument above applies to these two algorithms.
> 
> Yes. If that changes it would be in 5.1 (and the only thing I see changing there would be additions, due to <template> or something like that). So good.
> 
>> ----------------------------------------------------------------------
>> Section 5.5.2 Processing RDFa Attributes
>> """
>> The rules for modification of URL values can be found in the main HTML5
>> specification under Section 2.6.2: Parsing URLs.
>> """
>> 
>> The same argument above applies to this algorithm.
> 
> Yup. Likewise, the parsing of URLs is likely to be improved (notably by Anne's work on URL handling) but that would be in the 5.1 branch.
> 
>> ----------------------------------------------------------------------
>> The general idea here is that the RDFa processor defers to the HTML5
>> algorithms when reading values from an HTML serialization and writing to
>> an HTML5 or XML serialization. Doing otherwise would be a layering
>> violation. If the HTML5 algorithms were to change, nothing would have to
>> change in the RDFa processing algorithm since the RDFa processing
>> algorithms make no assumptions about the tree-based model that they're
>> given.
> 
> That makes sense.
> 
>> The other protection provided by RDFa processor implementers is that all
>> of them, to date, have not attempted to re-implement any of the
>> algorithms outlined by the HTML5 specification, but have rather depended
>> on 3rd party libraries to provide the necessary HTML5 functionality.
> 
> Which IMHO seems sane.
> 
>> The 3rd party library maintainers are the ones that will update their
>> implementations if the HTML5 algorithms change. It is highly unlikely
>> that a change to the HTML5 algorithms in a 3rd party library will result
>> in breakage or required modifications in an RDFa processor.
> 
> To put this differently: if we were to introduce changes in those algorithms that broke RDFa, they would be very likely to break a lot of other things too (XML coercion less than the others, but parsing HTML and URLs definitely a lot). So we wouldn't do it.
> 
> You're all clear from our end.
> 
> -- 
> Robin Berjon - http://berjon.com/ - @robinberjon
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Monday, 18 March 2013 13:54:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:58 UTC