Re: Resolving tag location during call to createElement() in acustomDocumentImpl

[Maitreyee Pasad <pa...@gst.com>]

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

oshea2j@ie.ibm.com 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.
>
> oshea2j@ie.ibm.com 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 : oshea2j@ie.ibm.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org