You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Peter Murphy <pe...@fast.fujitsu.com.au> on 2001/03/12 03:15:32 UTC
Xerces related exception (RE: Working with DOM input and output destroyed...)
> -----Original Message-----
> From: Christian Aberger [mailto:Christian@Aberger.at]
>
> Peter,
>
> I wonder why you get output in first test case at all.
>
> Could you please do the following:
> Change line 106 in your sample to:
> domInput->setToCreateXMLDeclTypeNode(false);
>
> and redo the test and send results.
Christian,
I did as you suggested: changed the sample, and redid the tests. [*]
(a) Process foo.xml using foo.xsl. Result: it works.
> ----------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <outor>Hello</outor>
> ----------------------
Thanks for that, Christian. But it seems odd that adding a XMLDeclTypeNode
causes empty output...
(b) Process foo2.xml (with PI using foo.xsl). Result: "Exception caught!!!"
This worried me, so I stepped through the code. The problem seemed to be in
XSLTEngineImpl::process - lines 370 and 371 in fact.
// ... goes through code to identify PIs, and pushes hrefs in.
----------------------------
while(!hrefs.empty())
{
const XalanDOMChar* const pxch = inputSource.getSystemId();
const XalanDOMString sysid(pxch);
----------------------------
Unfortunately, pxch is set as 0x00000000, so this causes an assertion in the
sysid constructor. Any reason why this is happening?
Regards,
Peter.
[*] Orginally, line 45 also read:
cerr << "Usage: SimpleDOMTransformer XMLFileName XMLOutFileName
[XSLFileName]" << endl;
For accuracy's same, "SimpleDOMTransformer" should be changed to
"SimpleDOMTransform". But that's not so much a bug as a feature...
P.
RE: Xerces related exception (RE: Working with DOM input and output destroyed...)
Posted by Peter Murphy <pe...@fast.fujitsu.com.au>.
> -----Original Message-----
> From: Christian Aberger [mailto:Christian@Aberger.at]
>
> Peter,
>
> Let us discuss it step by step, and let me give a summary from my
> point of view of what happened until now.
>
OK.
> <(a) Process foo.xml using foo.xsl. Result: it works.>
> OK. then we have the same results, thats good, and we have a
> working sample how to transform an already parsed in-memory DOM
> tree with xalan, that is even better.
>
I think the sample needs some testing myself. The foo.xml and foo.xsl are
very simple files; I'd like to try the program with more test cases. On the
other hand, it's a good place to start. I actually intended the file as a
sample program (or at least a starting point for a sample program) for
future releases of Xalan C++. I'd like to know what others think: does
anyone have any problem with this?
[...]
> I like the current version of Xalan-C a lot. If it is only a
> problem of programming capacity and there is a chance that it
> will be merged, I can try to add the support of XML_DECL_NODE so
> that the current version of xalan is function complete in that
> point and send it to somebody who has the permission to check it
> in. Even if it is only an intermediate solution until it is done
> in a standard way.
>
I wouldn't mind it myself.
> Sorry, I did not look into the 2nd sample yet, maybe this should
> be discussed independently of the case 1)
>
I'll submit it to Bugzilla - that seems like a weird problem.
> wfR ChrisA
>
Regards,
Peter.
RE: Xerces related exception (RE: Working with DOM input and output destroyed...)
Posted by Christian Aberger <Ch...@Aberger.at>.
Peter,
Let us discuss it step by step, and let me give a summary from my point of
view of what happened until now.
<(a) Process foo.xml using foo.xsl. Result: it works.>
OK. then we have the same results, thats good, and we have a working sample
how to transform an already parsed in-memory DOM tree with xalan, that is
even better.
<But it seems odd that adding a XMLDeclTypeNode causes empty output...>
Yes, this is absolutely also my opinion. This is due to the absence of
implementation of XML_DECL_NODE in the Bridge within Xalan.
Dave Bertoni already answered this:
"XML_DECL_NODE is not a standard DOM node type. We have no plans to support
it since it will be replaced by a standard mechanism."
I replied to that in a separate thread, which maybe should be discussed
under this topic:
<<...Well, I suppose there are 2 (out of many) aspects of softwarequality
concerned in this point: conformance and correctness. I agree that
XML_DECL_NODE is not a standard. Still, when Xerces is used as inner
implementation of an outer interface, there is among all other allowed
enumeration values of "NodeType" also the value XML_DECL_NODE. This is a
valid value of a membervariable. Parsing a valid input document with XMLDecl
set to "true" is a valid operation that transits to a valid program state.
In a correct program valid states have transitions to the set of all valid
states only. So not implementing XML_DECL_NODE is, in my personal opinion,
not correct although it is conforming...>>
No answer on this yet.
I like the current version of Xalan-C a lot. If it is only a problem of
programming capacity and there is a chance that it will be merged, I can try
to add the support of XML_DECL_NODE so that the current version of xalan is
function complete in that point and send it to somebody who has the
permission to check it in. Even if it is only an intermediate solution until
it is done in a standard way.
Sorry, I did not look into the 2nd sample yet, maybe this should be
discussed independently of the case 1)
wfR ChrisA
-----Original Message-----
From: Peter Murphy [mailto:peterm@fast.fujitsu.com.au]
Sent: Montag, 12. März 2001 03:16
To: xalan-dev@xml.apache.org
Subject: Xerces related exception (RE: Working with DOM input and output
destroyed...)
> -----Original Message-----
> From: Christian Aberger [mailto:Christian@Aberger.at]
>
> Peter,
>
> I wonder why you get output in first test case at all.
>
> Could you please do the following:
> Change line 106 in your sample to:
> domInput->setToCreateXMLDeclTypeNode(false);
>
> and redo the test and send results.
Christian,
I did as you suggested: changed the sample, and redid the tests. [*]
(a) Process foo.xml using foo.xsl. Result: it works.
> ----------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <outor>Hello</outor>
> ----------------------
Thanks for that, Christian. But it seems odd that adding a XMLDeclTypeNode
causes empty output...
(b) Process foo2.xml (with PI using foo.xsl). Result: "Exception caught!!!"
This worried me, so I stepped through the code. The problem seemed to be in
XSLTEngineImpl::process - lines 370 and 371 in fact.
// ... goes through code to identify PIs, and pushes hrefs in.
----------------------------
while(!hrefs.empty())
{
const XalanDOMChar* const pxch = inputSource.getSystemId();
const XalanDOMString sysid(pxch);
----------------------------
Unfortunately, pxch is set as 0x00000000, so this causes an assertion in the
sysid constructor. Any reason why this is happening?
Regards,
Peter.
[*] Orginally, line 45 also read:
cerr << "Usage: SimpleDOMTransformer XMLFileName XMLOutFileName
[XSLFileName]" << endl;
For accuracy's same, "SimpleDOMTransformer" should be changed to
"SimpleDOMTransform". But that's not so much a bug as a feature...
P.