John: I didn't really need a DOM. All I needed was a subtree of elements and Attributes at a time. So which ever "ElementHandler" would require to store the subtree under it, it would just store a tree of elements and attributes using a simple Tree data-structure. With this method I don't have access to any fancy DOM manipulations.
I would think if you need full DOM functionality then you may need to do a lot more work. In that case you are right it would be like using a sledgehammer to cut paper. I used a modification of the The Rule Based Design Pattern for SAX Parsing mentioned in "Professional XML" published by Wrox. Hope this helps. Maitreyee [EMAIL PROTECTED] wrote: > Hi Maitreyee, > > > Did you consider using the SAX Parser to create the DOM on your > > own? In that case you will have a call back when an element goes > > out of scope. > > > > We have implemented something similar to that approach using a stack > > like you mentioned. > > I thought about this, briefly, but it sounded like using a sledgehammer to > cut some paper :) I'm hoping there's a simpler solution. since such tag > name clashes are common and may be more so with the built-in support for > scoped element definition in XML Schemas (assuming one namespace). Perhaps > an API needs to be added to DocumentImpl to support XPath qualified > identification of tags during DOM parsing? Or is it unreasonable to think > that DOM parsers should be able to handle this? I wouldn't think so. > > Aside, how much effort did you expend using the SAX parser to create the > DOM? > > Regards, > > j. > > [EMAIL PROTECTED] wrote: > > > Hi, > > I'm extending the Xerces DocumentImpl class and using the parser > property > > http://apache.org/xml/properties/dom/document-class-name to get the > XercesJ > > parser to use my implementation class when parsing the XML document. In > > conjunction, I've written a collection of classes which extend the base > > ElementImpl class and provide application level APIs for manipulating the > > XML document. On calls to DocumentImpl.createElement() from the parser, > my > > DocumentImpl chooses an ElementImpl, instanciates it, and returns it to > the > > parser. The parser then inserts it into the DOM. Once parsing is > > complete, I have a DOM which is also a set of related objects which > > implement a set of application level interfaces. These application level > > interfaces allow navigation and manipulation of the underlying data > without > > exposing XML or DOM (The reason for doing this is the application API > > framework is generic and is also implemented using other > > technologies/transports. > > > > This is all well and good but I've hit a snag when overriding > > DocumentImpl.createElement(). The parser just gives me the tag name the > > parser has just encountered and expects an ElementImpl in return. > However, > > the initialization required for my custom ElementImpl instances for each > > tag name depends on *where* in the XML document the tag is located. > > > > Let me give an example: > > > > <person> > > <name> > > <first>XXX</first> > > <last>YYY</last> > > </person> > > > > <car manufacturer="Mercedes"> > > <name>500SEL</name> > > </car> > > > > I have two classes which represent Elements with the tag <name> - one for > > People and one for Cars. Each provides a set of application APIs for > > accessing the name of that type of object. However, during parsing, my > > DocumentImpl cannot distinguish between a "person/name" and a "car/name" > so > > it can't tell which type of ElementImpl to create. (You may say this > > example uses bad XML Schema/DTD design but it does illustrate the problem > > I'm confronted with. I need to be able to cater for cases where such tag > > name collisions occur in the underlying XML data.) > > > > So is there any way for my DocumentImpl to determine, during the parsing > > phase, where in the document the current tag is? Ideally Xerces would > give > > me an XPath string instead of just the tag name - that would solve my > > problem but it doesn't seem to be the case :( Has anyone got any > > suggestions as to a viable alternative? I thought about implementing a > > stack inside my DocumentImpl to keep track of the elements the parser is > > creating but there is no callback to indicate when a tag scope is closed, > > allowing me to pop that tag off the stack. > > > > Any suggestions welcome! > > > > j > > > > John O'Shea, > > Phone : + 353 1 8154228 Email : [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
