On Monday, August 27, 2001, at 12:57 AM, Craig R. McClanahan wrote:
> On Sun, 26 Aug 2001, Jason van Zyl wrote:
>
>> Date: Sun, 26 Aug 2001 19:15:29 -0400
>> From: Jason van Zyl <[EMAIL PROTECTED]>
>> Reply-To: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED]
>> Subject: [digester] dynamic digester via DTD/Schema
>>
>> Hi,
>>
>> Has anyone played with making a Digester that works generically from a
>> DTD
>> or Schema? Robert, I think you started something yes? It would be very
>> cool
>> point a DynamicDigester at a DTD/Schema and not have to worry about the
>> making the rules yourself :-)
>>
>
> I can see how you'd decide what patterns made sense from a DTD or a
> Schema, but how would you decide what rules to fire? Even if it's a
> simple "instantiate an object tree that is isomorphic to the XML
> document", you'd still have to decide how to map XML elements to Java
> class names, deal with attribute<-->property mismatches, and so on -- to
> say nothing of figuring out what method names to fire for SetNextRule
> calls ... by that time, you might as well just go ahead and make the
> rules.
(it depends on how complex the schema is. i bet that the batik team over
in xml-land really loved having to rewrite their DOM implementation when
the standards body changed the SVG schema. generating DOM implementations
seems easier to me :)
in general, i think that craig's right. xml-> object model mappings can
get very complex and - in general - there's no way to avoid a lot of
effort.
*but* so long as we're not trying to create a generic solution, a solution
for common mapping problems might be useful. i've hand-coded digester
rules for reasonably large schema's and it does take some time and effort.
for complex mappings, you probably have to hand-code the rules - but for
simple, regular mappings it could save a lot of time where you have a
large number of elements. also it might save the time needed to learn
digester rules in detail. at the very least, it'd be useful to have most
of the code generated and then start tweaking the complicated bits.
in many cases you'll want xml to be represented by nice familiar java
beans - and these beans will probably follow a very simple set of naming
conventions.
for example, elements map to object names and attributes to bean
properties. a more variable question is how child objects attach
themselves to their parents. in java, a one-to-one relationship might be
mapped to a property and a one-to-many to a appendXXX method. a common
naming convention would be to use the name of the object. (the one thing
that i can't guess is where the body text would go - into a constructor
maybe?)
in this way you can come up with a set of conventions (extending the java
bean naming conventions) that you can generate beans and rules from.
equally well, you can dynamically create these rules from the schema and
use existing beans.
i have been thinking about the problems of naming mismatches similar to
the ones that craig's raised and there's no getting away from them - but
in the cases that generated rules would be useful, i don't think that they
are such a problem. for generated beans, there would be no problem with
mismatches. for xml schema produced with the intention of mapping to an
existing java object model, then there should be no problem so long as the
xml naming is created sensibly from the model. (i suppose that the xml
schema could be generated by introspection in the first place in this case.
) if people found that this was so amazingly useful that they wanted to
extend it beyond this kind simple stuff then they could always submit
patches :)
in terms of technical details, i have been working on an extension to the
standard patterning matching rules that allows (amongst other things)
these kinds of relationships to be specified concisely. the reason why i
haven't submitted it (yet) is that the algorithm is really pretty complex.
i think that it's debugged now but i want to create a set of unit tests
to make sure that it does what it should and also come up with a document
detailing the matching rules and how they apply in combination. this will
take some time and isn't a huge priority for me at the moment. (with a
little prodding i could try to push it higher or submit a beta.)
- robert
