Re: Suggested revised text for HTML/XML report intro

I think the key question is whether are enough real world demand to
justify doing the amount of work it would take to do the mapping and write
the tools that could unify the stacks.  The impression I've gotten from
participating in this task force is that there is not.


On 8/17/11 7:58 AM, "Noah Mendelsohn" <nrm@arcanedomain.com> wrote:

>
>On 8/16/2011 6:45 PM, John Cowan wrote:
>> What would be the benefit of lenient XML parsing in the XHTML context?
>> You might just as well use the HTML syntax.
>
>I >think< what it allows you to do is to start migrating toward use of an
>XML-stack and perhaps use of some new media type (maybe
>application/xhtml+xml5?). First of all, you are more likely to be able to
>do a mechanical mapping of your old broken HTML, perhaps just be serving
>it 
>as is under the new media type. You get the debugging "benefits" of not
>having your entire page fail to render just due to mismatched quotes on
>one 
>attribute (and yes, there's a debugging cost to more lenient error
>checking).
>
>Finally, if people choose to go that route, you have a defined mapping
>that 
>allows all of this somewhat broken data to be managed by existing XML
>tools. For example, you might have an XML-aware database. Today, you can
>use it to manage XHTML, but not tag soup. Assuming you are aware of the
>risks, you can now move to a content management system where all your
>HTML 
>is run on such an XML database. Of course, where the input is not well
>formed, some of the mappings may not what you expect, and there will be
>questions when re-serializing of whether you expect back the tag soup or
>the fixed up XML. Still, there is some value there I think, especially as
>a 
>migration path toward unifying the stacks.
>
>Noah
>
>

Received on Wednesday, 17 August 2011 15:52:34 UTC