[
Lists Home |
Date Index |
Thread Index
]
> 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.
|
