Boost logo

Boost :

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2003-06-02 08:30:10


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 should conform to the following W3C standards:
> (a) XML 1.0 SE while looking at supporting XML 1.1 in the future;

yes

> (b) DOM 1.0/2.0/3.0

I would argue about that. these specs are considered broken in many
ways. Also, they are not particularly 'C++ friendly'. I'd start with
a 'C++ API' that really fits into the language (and surrounding libs
such as libstdc++ or boost), and then provide API mappers on top of
that to conform to whatever people need/want.

> (c) XPath 1.0 with XPath 2.0 support in the future (switch between
> them??)

yes

> (d) Unicode 3.x support (I know this is not a W3C standard, but it is
> related)

I'd argue that XML and unicode are quite unrelated (read: orthogonal).
Let me explain: I have been proposing to wrap an existing xml library,
which deals with the i/o. The internal representation is utf-8
('char *'). The XML API I actually provide through my wrapper is
DOM-like tree manipulation, node lookup (XPath), reading/writing,
and of course a SAX-like API.
None of this requires direct unicode functions. That's why I
parametrized the code for specific string types, so the user can
'plug in' his own string types and let them do the work. No need to
make the XML API more feature-rich than it needs to be.

> while these standards would be useful to have support for:
> (e) XSLT 1.0 with XSLT 2.0 support in the future (select which to use?)

nice-to-have, but not really necessary for a xml library.

> (f) XMLSchema 1.0

yes

> these standards are optional, but should be implementable using the base
> standards:
> (g) XSL:FO 1.0
> (h) MathML 1.0/2.0
> (i) SVG 1.x/2.x - Scalable Vector Graphics
>
> NOTE: The library should be capable of evolving as the web standards
> evolve.

That's a lofty goal. :-)

> [3] It should have W3C DOM bindings for the XML document in a way that
> allows support for adding extensions to this, e.g. providing a MathML or
> SVG DOM on top of the XML DOM.

yeah, probably on a wrapper layer on top of the 'core'.

Regards,
                Stefan


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk