You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by os...@ie.ibm.com on 2001/03/30 17:40:52 UTC
Resolving tag location during call to createElement() in a custom
DocumentImpl
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
Re: Resolving tag location during call to createElement() in a
customDocumentImpl
Posted by Maitreyee Pasad <pa...@gst.com>.
John:
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.
Maitreyee
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