c++ xml parser

[markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org (Mark Woodward)]

On 04/22/2011 12:52 PM, Rob Hasselbaum wrote:
> On Fri, Apr 22, 2011 at 12:23 PM, Mark Woodward <markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org 
> <mailto:markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org>> wrote:
>
>     There are lots of XML parsers, i.e. systems like expat work fine, that
>     answers problem #1. The next problem is how do you represent the
>     data in
>     C++? How generic does it need to be? what attribute takes will you
>     recognize? will a <tag value='abcedf'/> be sufficient? Or does it need
>     to be <tag>abcdef</tag>? Can it be both? Where's your data type
>     represented, in the tag or a type attribute?
>
>
> The purpose of an XML parser/serializer is to help you transfer data 
> between an external XML document and your program's domain object 
> model. So the problem your describing is only a problem within the 
> relatively narrow scope of the code that does the marshalling and 
> unmarshalling. It's not a great idea to use the XML parser's objects 
> (e.g. Node, Entity, Attribute, etc.) to represent the data within your 
> business logic because that couples your code to the parser's API and 
> the XML document format in a very pervasive way.

I call shenanigans!

The first sentence: "The purpose of an XML parser/serializer is to help 
you transfer data between an external XML document and your program's 
domain object model. "  That's problem #2 in my original post "the 
object model."

Addressing the second sentence: "So the problem your describing is only 
a problem within the relatively narrow scope of the code that does the 
marshalling and unmarshalling." That is part and parcel of problem #2 in 
my original post, how do you define the document model.

Third sentence: "It's not a great idea to use the XML parser's objects 
(e.g. Node, Entity, Attribute, etc.) to represent the data within your 
business logic because that couples your code to the parser's API and 
the XML document format in a very pervasive way."

There needs to be a definition of the fields and the variants and how 
they are represented that can be understood by the document parser (not 
just the XML parser). Eventually you do need to get the data into a form 
on which it can be worked on programmability. Seeing as C++ seems to be 
an end point, I think its safe to assume what ever action that is going 
to be taken on the XML will be implemented at the C++ level.

I wasn't implying any particular sort of architecture or model, I was 
enumerating the issues.

In my particular implementation, I treat all XML types as variant 
containers. It ends up being easier that trying to painstakingly map XML 
to some underlying C++ structure.