Re: XML payloads in feeds

Sam Ruby wrote:
> On 01/10/2011 04:50 AM, Henri Sivonen wrote:
> > So we both agree that the problem is temporary but we disagree on
> > how
> > to react to the temporary state of affairs while it lasts? (My
> > reaction is that things will get better soon enough, so it doesn't
> > make sense to design elaborate interim solutions around the
> > limitations of legacy tools on the content producer side.)
> 
> Everything is temporary. Including HTML5.
> 
> In this case, I think the problem will last a decade or more, and
> merits documentation and perhaps some accommodation.

It's worth noting that documenting issues with legacy tools is different from documenting the polyglot subset of HTML5 and XHTML5. (Note: I'm not suggesting that you suggested anything about them being the same thing.) So to the extent the problem merits documentation, the Polyglot Markup document is not it.

Documenting what the polyglot subset is is relatively less murky than documenting issues with legacy tools. As long as "polyglot" is defined as a byte stream that (with the exception of how xmlns="http://www.w3.org/1999/xhtml" is represented) results in the same DOM when parsed as HTML and as XML, the results can be discovered by logical inferences from specs without having to research real software.

With legacy tools, there's the question of which tools are important enough to have their limitations documented. Then someone has to actually test the tools. Then there's the issue that tools change over time and it's unfortunate if people keep working around limitations that are no longer there. To avoid this problem, the documentation would probably need to be continuously maintained and the connection between a particular legacy tool and a particular workaround shouldn't get forgotten. Otherwise, workarounds may continue to have a mythical life even after the software whose limitations are being worked around is no longer relevant. For example, an edited version of Appendix C was published in 2009 as Appendix A of the second edition of the XHTML2 WG's XHTML Media Types Note. Yet, even the 2009 edit contains the advice to put a space before /> in <br /> even though the necessity of the space has been long gone together with some legacy browser that predated Netscape 4. (I don't even remember for sure which browser.)

I do think that having well-maintained documentation about the limitations of legacy tools would be nice to have, though. Do we have a maintainer? ("Well-maintained" pretty much excludes /TR/ as a publication venue due to the bureaucracy needed for updates.)

> Whether HTML5 already
> has
> sufficient accommodation or whether adjusting things like the parsing
> of
> </br> merits revisiting is not something I am taking a position on.
> 
> Meanwhile, you continue to use terms like 'elaborate' in order to
> further your personal agenda.

I think you are seeking to further yours by expressing things that way. :-)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 10 January 2011 15:19:15 UTC