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

Re: Other HTML5 feature dependencies

From: Robin Berjon <robin@berjon.com>
Date: Mon, 18 Mar 2013 14:40:43 +0100
Message-ID: <5147195B.3080305@berjon.com>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: RDFa WG <public-rdfa-wg@w3.org>, "Michael(tm) Smith" <mike@w3.org>
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
Received on Monday, 18 March 2013 13:41:23 UTC

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