Re: ISSUE-4: Basis of the appeal to "XML editing workflows"

On Mar 10, 2010, at 18:43 , Tantek Celik wrote:
> FWIW I have implemented an XML workflow on my own site[1] that works just fine with processing biglot HTML5 documents with <!DOCTYPE html> (which I use as a data store) and produces text/html "safe" biglot documents.
> 
> So its certainly possible to do so. And frankly wasn't that hard (using PHP DOMDocument even). YMMV.

As a further FWIW data point, that's exactly what I do as well on http://berjon.com. It uses Perl and XSLT (through the libxml and libxslt bindings) and I met with practically no issue while developing it. XSLT does produce a DOCTYPE which I remove in post-processing — I may be missing something but I don't know of any good XML publishing system that would not allow for such trivial post processor. If anything is to be done about this, I would encourage coordinating with the XSL WG to define whatever small changes are required to XSLT 1.0 to support producing <!DOCTYPE html>. Note that this is supported by XSLT 2.0's xsl:output by setting method to xhtml and version to 5, and could be supported in 1.0 with output method html and the same version information, but support for it is currently implementation-defined. A specification to plug that hole and make the serialisation method more clearly defined would be very simple. If needed, I don't mind working with the XSL WG on producing this.

I believe that point #4 ("XML workflows often require a !DOCTYPE with a PublicIdentifier and a SystemIdentifier") requires stronger evidence, that the value of version indicators even in "limited situations" is currently unproven (see [0]), and more importantly the case in point #11 is does not sufficiently back the proposal.

Allow me to expand on the later point. We are considering a future change to HTML in which an incompatibility is introduced that is not covered by the current processing rules. That means that it is not a situation in which a new element or attribute is introduced (unknown elements and attributes have clear processing rules) but rather a case in which an existing construct changes meaning. I presume that the goal of the proposal is that implementations that predate the change would be expected to process the document differently if it indicates that it makes use of a version that the implementation has no knowledge of. If such a change in behaviour is not required, it is unclear how the proposal helps mitigate issues introduced by incompatible change. Nevertheless, the proposal states that "does not require any changes to any browser or HTML interpreter; existing behavior is maintained." I therefore fail to see how it is intended to be helpful.

As a side note, speaking as a member (but not on behalf) of the HCG, I would rather we not spend time coordinating FPI assignation, as proposed.

[0] http://lists.w3.org/Archives/Public/www-tag/2009Dec/0116.html

-- 
Robin Berjon - http://berjon.com/

Received on Monday, 15 March 2010 18:28:03 UTC