Stefan Seefeld said:
> Vincent Finn wrote:
>>> What I did was to provide a *thin* wrapper around the internal C
>>> strucs used by libxml2, so every dom manipulation call can be
>>> delegated down to libxml2. For example xpath lookup: I call libxml2's
>>> xpath API, returning me a C structure (pos
Vincent Finn wrote:
What I did was to provide a *thin* wrapper around the internal C strucs
used by libxml2, so every dom manipulation call can be delegated down to
libxml2. For example xpath lookup: I call libxml2's xpath API, returning
me a C structure (possibly) holding a node set, i.e. a list o
What I did was to provide a *thin* wrapper around the internal C strucs
used by libxml2, so every dom manipulation call can be delegated down to
libxml2. For example xpath lookup: I call libxml2's xpath API, returning
me a C structure (possibly) holding a node set, i.e. a list of C
nodes. I just ne
Stefan Seefeld wrote:
[snip]
But providing a different binding may practically be very hard, i.e.
require a lot of work. Again, don't focus on parsers only. There is
*much* more...
What I was thinking of in the code I e-mailed previously was something like:
class document
{
private:
elemen
Reece Dunn wrote:
That said, I would *not* recommend to rewrite any such thing. It is
a *lot* of work, and as such quite unrelated to boost's goals.
Would also mapping an implementations structure to a C++ internal
structure also require quite a bit of work?
yes ! As I said, parsing is only a s
Stefan Seefeld wrote:
What I originally suggested was not a parser, but a set of APIs to
manipulate XML. The parser part (i.e. the piece of code that generates
a parse tree from an XML file) is the simples part of it all. What
is much more tricky is to get the right internal structure to make
oper
Reece Dunn wrote:
[1] It should make use of the Spirit and Regex libraries for XML and
XPath parsing.
note that parsing is only a small part of it. A dom-like API for example
needs heavy support from the internal structure for things like
namespace, entity, node (xpath) lookup, etc.
[2] It sh
What I originally suggested was not a parser, but a set of APIs to
manipulate XML. The parser part (i.e. the piece of code that generates
a parse tree from an XML file) is the simples part of it all. What
is much more tricky is to get the right internal structure to make
operation on the tree effic
Reece Dunn wrote:
Anthony Williams wrote:
> Writing an XML parser from scratch for boost should, IMHO, have these
> features:
[snip]
Writing a lexer/parser is a complex task. It wasn't a requirement, more
a suggestion/my opinion on what a boost XML library should be like.
There are four possibl
Anthony Williams wrote:
> Writing an XML parser from scratch for boost should, IMHO, have these
> features:
> [1] It should make use of the Spirit and Regex libraries for XML and
XPath
> parsing.
Whilst these libraries might be useful for the parser writer, I don't see
any
benefit to requiring
"Reece Dunn" <[EMAIL PROTECTED]> writes:
> Writing an XML parser from scratch for boost should, IMHO, have these
> features:
> [1] It should make use of the Spirit and Regex libraries for XML and XPath
> parsing.
Whilst these libraries might be useful for the parser writer, I don't see any
benefi
Having used the spirit lib to parse XML input in both mulit-byte and unicode input,
(in connection with the serialization library). I want to second the suggestion
to look into spirit in this context. The spirit package includes two examples
for parsing XML. It seems to me that the more elabor
For what it's worth, I've had great success using James Clark's expat to
populate directed graphs abstracted by a BGL adjacency list. I'm too busy to
document and submit to the sandbox at the moment but that should give anyone
interested enough information to go do it. Parenthetically, I've found t
Stefan Seefeld wrote:
Vladimir Prus wrote:
What is wrong with Xerces-C++ library
(http://xml.apache.org/xerces-c/index.html) ?
Probably, the fact that its tarball is comparable in size to the entire
Boost?
And, related, performance of the libxml2 is far better then any
compotitor. Of course, it
Vladimir Prus wrote:
What is wrong with Xerces-C++ library
(http://xml.apache.org/xerces-c/index.html) ?
Probably, the fact that its tarball is comparable in size to the entire
Boost?
And, related, performance of the libxml2 is far better then any
compotitor. Of course, it remains to be shown th
Aleksey Chernoraenko wrote:
>> I wrote a C++ wrapper library around libxml2 (http://xmlsoft.org/),
>> and would like to submit it to boost. It currently provides a DOM-like
>> and a SAX-like interface, is parametrized for the (possibly unicode
>> enabled) string type, and has already proven its va
16 matches
Mail list logo
