> I guess that this is my worry. If it created source code that could > seamlessly instantiate a DOM object that could be serialized, I would be > happier to go down this route, but if it is convoluted....
What I think is convoluted isn't necessarily for others, I'm just expressing my opinion based on the fact that I'm not fond of generated code as a rule. > Would your approach be to build the DOM from scratch then parse/validate > in memory, with the schema, then serialize? I haven't read the whole thread, so I don't know exactly what you're looking for. You can't actually validate in memory with Xerces-C. What I do is build classes by hand that contain what they need to contain and write adapters/stream operators that can seamlessly turn the objects into XML when they need to be (but not repeatedly at every turn). Most of that can be handled by a base class, with the subclasses overriding a toDOM() method to handle their piece of the tree. There's a constructor and virtual fromDOM() of course, to handle the other direction. I can also handle extension points with a simple factory metaphor where the built in elements/types are registered for me, but people can register extensions by providing their own classes that fit into the model, and the code can manufacture the right class at runtime based on xsi:type. What I particularly like is that I can pass back access to the actual DOM after parsing the XML, allowing unknown extensions to be visible to the caller without me knowing about them. I don't think regenerating code every time the XML changes a little is viable. A binary format is much more efficient if you're going to be that brittle. But mostly, I just like having control. Some things I would never implement myself just as a matter of rule (anything the STL provides for me, for example), but data binding isn't one of them yet. -- Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
