Node type 5 is an "entity reference node". Saxon can't handle a DOM
containing entity reference nodes, all the entities must have been fully
The entity reference nodes are there because you have set:
Do you really need them for your processing?=0D
--> I do need the entity references in my processing and want to make it in=
one shot. What I mean by this is that I can't parse my document once, do=
my processing with SAXON then serialize it again with the modifications=
and re-parse this serialized file (with entities references) to do another=
I have looked at the given stack trace and modified SAXON code=
('makeWrapper' method in the net.sf.saxon.dom.NodeWrapper class) by adding=
the following lines :
wrapper =3D new NodeWrapper(node, parent, index);
wrapper.nodeKind =3D Type.COMMENT;
It seems to work on my example but I was wondering if my modifications were=
valid or not and if any problem can occur whit this modification.
Thanks in advance,
This e-mail is intended only for the above addressee. It may contain
privileged information. If you are not the addressee you must not copy,
distribute, disclose or use any of the information in it. If you have
received it in error please delete it and immediately notify the sender.
Security Notice: all e-mail, sent to or from this address, may be
accessed by someone other than the recipient, for system management and
security reasons. This access is controlled under Regulation of
Investigatory Powers Act 2000, Lawful Business Practises.
From: Michael Kay <mike@sa...> - 2005-10-21 09:10:11
> I have looked at the given stack trace and modified SAXON
> code ('makeWrapper' method in the
> net.sf.saxon.dom.NodeWrapper class) by adding the following lines :
> case Node.ENTITY_REFERENCE_NODE:
> wrapper = new NodeWrapper(node, parent, index);
> wrapper.nodeKind = Type.COMMENT;
> It seems to work on my example but I was wondering if my
> modifications were valid or not and if any problem can occur
> whit this modification.
The answer is that it will almost certainly break something, but I can't
tell exactly what without a considerable amount of testing. It will probably
break any stylesheet that accesses real comments, because a DOM entity
reference node has a null nodeValue, and the code for processing comments
assumes a non-null nodeValue.
It's very often the case with things like this that you need to create 50
test cases to determine whether a three-line source change is viable: and in
the case of DOM code, you need to run these tests against three different
DOM implementations before you can be sure it's OK.
At the very least, your change will create a data model that is an incorrect
representation of the source document: the text or element nodes that are
children of the entity reference will not be visible as part of the tree,
and will not be copied by an xsl:copy operation. So even if the patch works
for you, it's certainly not a general solution.
If this facility is sufficiently important to you that your company would be
interested in sponsoring the development of a solution, please contact me