Re: XML-parser interface (Was: Unicode in C++)

From: williamkempf_at_[hidden]
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, 
eg.
> > 'wchar_t' and/or 'ucchar_t'.
> 
> That's exactly what I meant.  Obviously I am going to have to be a 
little
> 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 
on, if
> it is done with this goal in mind.  I guess it comes down to 
whether people
> want a nice, familiar, portable C++ XML parser in Boost (to begin 
with), or
> an elegant, portable C++ XML parser in Boost.  Down the track I 
don't see
> why both couldn't be provided, it just seems that the former could 
be
> brought up to scratch far more quickly, and with far less debate, 
than the
> latter (and the latter can be debated while the former is being 
completed
> :) ).

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.

Bill Kempf