
Alan Gutierrez wrote:
I'm not sure I understand what you mean by transformation. How is it different from update ? Or is the former simply a (coarse-grained) special case of the latter, using a particular language to express the mapping (such as xslt) ?
Transformation engines are XQuery, XSLT, STX, and Groovy GPath.
They do not update the document provided. The produce a new document. That is what I mean by transformation. The input XML document is not changed, it is read, and a new document is emitted.
Fine. An what API are you looking for to do such transformations ? What's the granularity that makes the most sense ? document_ptr document = parse_file(input); stylesheet_ptr transformer = load_stylesheet(stylesheet); document_ptr new_document = transformer->transform(document); ought to be enough, no ?
The document object model does not need to be mutable. Thus you can perform all sorts of optimizations for navigation.
Could you provide an example ? I'm not sure I see what you have in mind.
The ability to add or remove a node makes a document object model far more complex.
Really ? Look at my design, there aren't all that many methods to begin with, and only a fraction are about modifying documents / nodes. I believe that non-modifiable documents aren't that frequent that they require an entirely different object model.
Many people prefer this mode of operation over adding and removing nodes.
As I said, the idea of an API to navigate based on axes (for example) sounds very interesting and elegant, but I believe that could easily be layered on top of the API I'm presently proposing.
Node insert/remove appears to be a common operation, because of web programming, where chaning the dom in the browser changes the display of the page.
I don't quite agree that this is the number one use case. I haven't actually looked into boost::serialization, but I'd expect a DOM API to be useful there. I'v written libraries for data management that used some kind of DOM API, too. Or configuration data, or...
When you are not programminng for the pretty side-effects, node surgery becomes a real pain. Reading the document in, shuffling nodes, writing it back out is cumbersome. A lot of code is spent on the add and remove that is repetitious.
Ok, so let's make it concise then. But someone has to create the document that you want to read in and transform. And may be that someone would prefer boost::xml if it existed. :-) Regards, Stefan