Unfortunately there is no way of validating a DOM tree at this time. You
will have to create an XML document and parse it to validate the data
structure.

The only bright side of the situation is that if you wanted the XML document
as the result in the first place you already have it streamed and you can
use a simple SAX handler for the validation (since you do not require a DOM
tree or do no need to store the data since you already have it in your own
format).

/ Erik

-----Original Message-----
From: Matthew James Hanson [mailto:[EMAIL PROTECTED]]
Sent: den 4 januari 2002 00:03
To: [EMAIL PROTECTED]
Subject: RE: Parsing a non-stream input


Rather than have developers learn the string translation syntax of the
various Xerces (and Xalan, for that matter) string classes, I have been
asked to write a wrapper class using more familiar string and attribute list
classes (i.e., std::string, std::list, etc.).

Many of our external messaging interfaces are XML.  I was asked to have
classes available (i.e., xmlElement, xmlDocument, etc.) to abstract the
internal DOM & SAX knowledge away from the developer.  Developers are to
only build XML objects instead of, say, XML strings or documents.  I supply
the methods (element->setAttribute(), element->addChildElement(),
element->getChildByName(), etc.).

The class built by the developer still needs to be stringified and,
possibly, parsed according to many DTD documents we have defined.  I would
like to be able to take the hierarchy built by the developer and build a
parsable structure (DOM_Document or any other applicable class) to be passed
to the DOM, or preferably, SAX, parser.

Am I just way off base here?  Should I just stringify the tree supplied by
the developer and pass that as the InputSource to SAXParser?  I know that
Xerces obviously tokenizes any XML string parsed into objects.  I was hoping
to avoid having our developers create a tree, then I traverse the tree and
create a string, then Xerces tokenizes the string and creates its own
structures (at least twice as much work as needed?).  In the Xalan library,
we call methods (i.e.,  startDocument(), startElement()) to build up a XSLT
"document."  I was hoping a similar avenue was available in either DOM or
SAX.

Thanks for letting me ramble!
Matt Hanson!

 -----Original Message-----
From:   [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent:   Thursday, January 03, 2002 2:42 PM
To:     [EMAIL PROTECTED]
Subject:        Re: Parsing a non-stream input


Parsing, by definition, takes a stream of markup and parses it.  Since you
have an XML hierarchy which is not a stream of markup, there is no need to
parse it.

Perhaps if you explain the problem you are trying to solve and the
structure of your data, someone can help you out.

Dave




                      Matthew James
                      Hanson                   To:
[EMAIL PROTECTED]
                      <matthew.hanson@         cc:      (bcc: David N
Bertoni/CAM/Lotus)
                      wcom.com>                Subject: Parsing a non-stream
input

                      01/03/2002 01:11
                      PM
                      Please respond
                      to xerces-c-dev





Hi!

I need to parse an XML doc that is not a stream (file, buffer, etc.).
Technically, it is not yet an XML doc at all, but a wrapper class
representing an XML hierarchy.  I don't think I am supposed to build a DOM
tree, as no parse(...) method takes a DOM_Node as input.

Please help me to determine which classes I can use to build a non-stream
XML input to be parsed.

Thanks!
Matt Hanson!


---------------------------------------------------------------------
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]


---------------------------------------------------------------------
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]

Reply via email to