Cart
[Home] [By Thread] [By Date] [Recent Entries]
> I have no idea of what the handler classes would look like, > but my first try > at it would be a kind of application-specific DOM. The type > mapping would > build this application-specific DOM from a stream of SAX > events or from a > W3C DOM instance (since I think PSVI cannot be obtained in a > first-pass > parsing with SAX, the full document must be parsed first to > allow the PSV to > resolve some lookaheads). > That's actualy an approach that's being tried here, although straight off of the schema instead of the PSVI. You're going to take some performance hit working off of a generic data model such as a DOM, but it beats working with the DOM directly. One thing you're going to need is some higher-level classes, because any methods you generate off of a PSVI or Schema are going to be (by nature) fine-grained. People are going to want a Point() class, for instance, that takes x, y, and unit values, not set each individually. That calls for a layering approach. The method I'm advocating is to bypass DOM and head straight to generating objects from XML Schema (XML data binding), and then add a proxy layer over the top that the application works with. This insulates the app from having to immediately react to minor tweaks to the data model, which is important during development (as you don't want to bother the GUI guys too often [they're artistes, you know]). Now, this doesn't solve the new elements/attributes problem your approach does, but perhaps a hybrid approach could be where you use 'direct' object mapping via a code generation binding too, and a generic data model API for the new stuff. Not quite as sophisticated, but functional.
|
