You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Jens Lauer <Je...@iav.de> on 2004/10/05 18:26:22 UTC

creating fragments from XercesDOMParser parsed MemBufInputSource and ALTOVA code




Hi,

I' am about getting crazy with following problem - sorry, but It's a huge
description -

I have an DCOM-server sending some data as an serialized xml (via
DomWriter->writeToString( pToSomeXMLNode) ).
The data  is sended wrapped in an BSTR. In client-space I have to dewrap it
and try this approach:

1) convert BSTR to char * pXMLChars
2) create a new Pointer to MemBufInputSouce:

      MemBufInputSouce * memBufIS = new MemBufInputSource( (const
XMLByte*)pXMLChars
        , lCountOfBytes
        , gMemBufId
        , false
    );

3)instantiate a new XercesDOMParser Object:

      XercesDOMParser * d_parser = new xercesc::XercesDOMParser();

4)let it parse

      d_parser->parse(*memBufIS);

5) create a note and put the parsed data into it:

      DOMNode * pNode = d_parser->getDocument();

6) and now the problem - i have to add the parsed result to an Object
altova's XMLSpy has created for me ( because in DCOM server space it was
just serialized out of the altovas objects ).

I tried this:

      CIdentificationType cIdent( pNode );

(where CIdentificationType comes from YMLSpy)

and normaly I will have access to the object in this manner:

      if( cIdent.HasszIdentnumber() )
      {
            CString Info = cIdent.GetszIdentnumber();
      }

but in this way I will get an exception from the altova code and my opinion
is that it comes from that...

An object e.g. the mentioned CIdentificationType looks serialized in
DCOM-server-space like this:

XMLDump:          <Identification><szIdentnumber>3D0919995
</szTeilenummer><szFooBar_1> NONSENSE </szFooBar_1></Identification>

BUT after parsing it looks like this and this brings the altova code to
confusion ...

XMLDump:          <?xml version="1.0" encoding="UTF-16" standalone="no" ?>
<Identification><szIdentnumber>3D0919995   </szTeilenummer><szFooBar_1>
NONSENSE </szFooBar_1></Identification>

I believe that the leading informations are the reason for the
misbehaviour.

So I played with fragments because the nodes altova uses are fragments too:

DOMNode                             * pNode           =
d_parser->getDocument()->createDocumentFragment();


But this node WILL BE EMPTY after some XML dump!


Has anybody some better idea to reconvert this XML after having
deserialized it - Altova doesn't support loading from some other then URI -
they use parseURI()
For this help I would be really thankful, because my project-deadline comes
closer and closer ....


thanks in advance

-----------------------------------------------------------------------------------

Jens Lauer