W3C home > Mailing lists > Public > www-tag@w3.org > January 2009

Re: Comments on HTML WG face to face meetings in France Oct 08

From: David Orchard <orchard@pacificspirit.com>
Date: Fri, 23 Jan 2009 20:17:32 -0800
Message-ID: <2d509b1b0901232017g697b6be4n82d00e9d50fd1acf@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: www-tag@w3.org
That would be very interesting if we could actually create an XML5 parser,
and I'm in highly in favour of such a thing IFF it was used to allow XML in
HTML5.  Absent such a thing, somebody would be forced to use an HTML5
browser and then an API to extract the XML 1.0 infoset.  It's slightly more
palatable with the HTML5 language spec being separate from all the rest of
the browser functions, but not as ideal as XML5.

Cheers,
Dave

On Fri, Jan 23, 2009 at 1:30 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

>
> Noah Mendelsohn wrote:
>
>> Consider, though, a different use case, in which some of the same XHMTL
>> documents are to be stored in an XML database and their attributes and
>> other data used as the subjects of queries.  Now you have in intersting
>> tension.  The database will presumably deal only with well formed XML
>> documents, which means that the messier content that browsers deal with
>> won't work in the database, at least not in the obvious way.
>>
>
> Surely the reasonable way to build such a database is that upon ingest, the
> database management front end parses input and then stores in whatever
> internal representation that the database. The front end parser could be an
> "XML5" parser that could retrieve an XML 1.0 infoset out of an ill-formed
> input stream.
>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>
>
Received on Saturday, 24 January 2009 04:18:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:11 GMT