[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_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
