Péter Szilágyi wrote:
That's a good question. Also, it would still be a parser only, as opposed to any in-memory representation (tree ?) with assorted APIs. Such a parser may be sufficient if all you have in mind is an XMLReader-like API, but it surely isn't if what you want is a DOM, with XPath-based lookup, incremental validation, etc., etc.
In my opinion in order for an XML library to be useful, it should support parsing and generating XML documents, in-memory representation, construction and modification support, as well as at least basic validation.
I would think different XML APIs can co-exist (possibly sharing implementation). Some use cases really only require XML streaming / parsing, and such users shouldn't be forced to see a full DOM API. I think the way the XML specs are defined allows us to make such APIs rather modular / orthogonal.
I think you are missing the point. It's not an argument for any particular
encoding. Rather, the point is that there is no pre-defined mapping between Unicode (or other) encoding and any C++ character type.
I understand this, I was just thinking about how the different encodings could be represented as wstrings while keeping the string's base functionality (one wchat_t truly one char, not just part of it).
Right. But, as you have pointed out in your previous mail, only fixed-sized encodings can be used like this. Often you don't need / want random access, making UTF-8 a better choice. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...