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

[os...@ie.ibm.com]

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-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

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