Date: 2001-09-26 12:45:32
--- In boost_at_y..., "Damien Fisher" <dfisher_at_u...> wrote:
> ----- Original Message -----
> From: <dietmar_kuehl_at_y...>
> To: <boost_at_y...>
> Sent: Thursday, September 27, 2001 12:12 AM
> Subject: [boost] XML-parser interface (Was: Unicode in C++)
> > --- In boost_at_y..., "Damien Fisher" <dfisher_at_u...> wrote:
> > > Perhaps it would be a good idea to ignore unicode until boost
> > > finalizes its solution on the matter.
> > I wouldn't call it "ignoring" it but rather: Just don't bind the
> > Boost XML parser to a particular character type. Initially, we can
> > just use it with 'char' (which, BTW, makes debugging more
> > convenient unless you are using only Unicode aware tools) and at
> > any time instantiate it with appropriate other character types,
> > 'wchar_t' and/or 'ucchar_t'.
> That's exactly what I meant. Obviously I am going to have to be a
> clearer in how I express myself, it seems you are misunderstanding
a lot of
> what I say (my fault entirely). Sorry about that.
> > > So the next
> > > question would be: do we start with W3C interfaces first
> > You cannot implement a fast interface in terms of a slow one and
> > retain the efficiency. This should sufficiently answer this
> > question...
> Sure, that's true enough. But I wouldn't expect that exposing a DOM
> interface precludes providing an efficient separate interface later
> it is done with this goal in mind. I guess it comes down to
> want a nice, familiar, portable C++ XML parser in Boost (to begin
> an elegant, portable C++ XML parser in Boost. Down the track I
> why both couldn't be provided, it just seems that the former could
> brought up to scratch far more quickly, and with far less debate,
> latter (and the latter can be debated while the former is being
> :) ).
DOM simply can't provide an "efficient" model (at least easily) since
it basically requires holding the entire "document" in memory. It's
much better to start with SAX for this kind of thing.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk