- From: David Orchard <orchard@pacificspirit.com>
- Date: Fri, 23 Jan 2009 20:17:32 -0800
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: www-tag@w3.org
- Message-ID: <2d509b1b0901232017g697b6be4n82d00e9d50fd1acf@mail.gmail.com>
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 UTC