Other HTML5 feature dependencies

Ivan had asked that we go back through the entire HTML+RDFa 1.1
specification and find any other HTML5-specific features that we depend
on before we go to Proposed Rec for HTML+RDFa 1.1.

Mike, Robin, your input as to the stability of the features that the
HTML+RDFa 1.1 specification depends on would be appreciated. We're not
looking for a verification that the features won't change, we're looking
for verification that you don't know of any plans to change any of the
features listed below. If you do know of changes to the features below,
the changes must significantly impact the future operation of an RDFa
processor to be considered destabilizing.

Here are the remaining HTML5 features that the HTML+RDFa 1.1
specification references:

----------------------------------------------------------------------

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.

It is also highly unlikely that an RDFa processor implementer would
implement this algorithm. Of all current RDFa processor implementers,
nobody has attempted to re-implement the HTML5 parsing algorithm. All
RDFa processors that parse HTML5 documents use a standard HTML5 parsing
library and this practice is expected to hold for future parsers.

Since the operation of the RDFa Processing algorithm on the input
tree-model is independent of how the tree is built, there really isn't
anything that RDFa processor authors would have to be aware of or change
in the event of an update to the HTML5 parsing algorithm. RDFa
processors operate on the tree model that is handed to them, even if
that tree model changes over the years, it is highly unlikely that the
HTML+RDFa 1.1 specification text will have to change as a result.

----------------------------------------------------------------------

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.

----------------------------------------------------------------------

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.

----------------------------------------------------------------------

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.

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.

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.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/

Received on Monday, 18 March 2013 01:18:03 UTC