RE: Resolving tag location during call to createElement() in a cu stom DocumentImpl

[Mark Sizer <mr...@cybercrop.com>]

Are namespaces out of the question?

-----Original Message-----
From: oshea2j@ie.ibm.com [mailto:oshea2j@ie.ibm.com]
Sent: Friday, March 30, 2001 8:41 AM
To: xerces-j-user@xml.apache.org
Subject: 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

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