On Tue, 2004-07-27 at 13:17, Rich Coco wrote: > but what if a Part object could be member of other objects > that are represented as xml elements, eg, consider an xmlrpc > msg fragment: > > <struct> > <member> > <name>Struct_1</name> > <value> > <array> > <data> > <value> > <struct> > <member> > <name>Struct_2</name> > . . . > > > Struct_1 can contain a Part element (not shown). > It also contains an array of Struct_2 elements, > one of whose members can either be a Part or another > structure containing a Part, etc... > > Suppose you need to parse the xml and return, say, a hashtable > containing the associated java objects. > > you may assume you know a priori the definitions for all > structure types (in xml). and assume you even have alreay generated > Java class definition for each such structure. (not hard using digester > if you have an input spec (in xml of course) defining the strucures, > giving them a name, specifying the members and their types, etc... > > it does not seem to me the "*/part" type of pattern will work. > this approach does not keep the correspondence between a <part> strucuture > and its parent container(s). > > it's a gnarly problem me thinks...one i eventually have to solve.
If you need to treat Part objects differently depending upon their parent element, then you can use these patterns: */struct_1/part */struct_2/part */part/part Here, I presume that when processing a part nested within a part, it doesn't matter what the parent of the top-level part is. I can't imagine a scenario where this would not be the desired behaviour. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
