Mailing-List: contact general-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xml.apache.org
Message-ID: <580DF4AEAC15D411A1D200508BA0E7E40274450A@mail>
From: Bentley Drake <bentley@nightfire.com>
To: "'edwingo@sun.com'" <edwingo@sun.com>
Cc: "'general@xml.apache.org'" <general@xml.apache.org>
Subject: FW: Crimson 1.1.3 bug and behavior changes?
Date: Mon, 5 Nov 2001 18:44:01 -0800 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"

Edwin,

Thanks for the responses.  I got the serialization approach from the
following site: http://xml.apache.org/~edwingo/jaxp-faq.html

"Note there are several implementation-dependent ways of doing this such as
using the org.apache.xml.serialize package in Xerces or the
XmlDocument.write(OutputStream) method in Crimson, but this ties your
application to particular parsers and is thus non-portable."

I also tried the following Trax approach (similar to that suggested in your
ApacheCon 2001 presentation):

            TransformerFactory tf = TransformerFactory.newInstance( );
            
            Transformer serializer = tf.newTransformer( );
            
            serializer.setOutputProperty( OutputKeys.INDENT, "yes" );
            
            Source source = new DOMSource( doc );
            
            StreamResult result = new StreamResult( new StringWriter() );
            
            serializer.transform( source,  result );
            
            return( result.getWriter().toString() );

However, this requires a Xalan implementation, which i'd rather not use at
this time.


>From the APIs, it looks like the preferred way of copying a DOM Document is
the cloneNode() method, found on the Node interface:

public Node cloneNode(boolean deep)

     Returns a duplicate of this node, i.e., serves as a generic copy
constructor for nodes. The duplicate node has no
     parent; ( parentNode is null.). 
     Cloning an Element copies all attributes and their values, including
those generated by the XML processor to
     represent defaulted attributes, but this method does not copy any text
it contains unless it is a deep clone, since
     the text is contained in a child Text node. Cloning an Attribute
directly, as opposed to be cloned as part of an
     Element cloning operation, returns a specified attribute ( specified is
true). Cloning any other type of node
     simply returns a copy of this node. 
     Note that cloning an immutable subtree results in a mutable copy, but
the children of an EntityReference
     clone are readonly . In addition, clones of unspecified Attr nodes are
specified. And, cloning Document,
     DocumentType, Entity, and Notation nodes is implementation dependent.
     Parameters:
          deepIf - true, recursively clone the subtree under the specified
node; if false, clone only the node
          itself (and its attributes, if it is an Element).
     Returns:
          The duplicate node.

I'm wondering about the following text in the javadoc wrt Crimson: "And,
cloning Document,
     DocumentType, Entity, and Notation nodes is implementation dependent."

If I already have a Document object, why is the cloneNode() failing?
Presumably an in-memory Document is already a valid object, and the cloning
is an identity operation.  If cloneNode() is not the preferred method, can
you suggest a better one?

Thanks,

Bentley


-----Original Message-----
From: Edwin Goei [mailto:edwingo@sun.com]
Sent: Monday, November 05, 2001 11:18 AM
To: general@xml.apache.org
Subject: Re: Crimson 1.1.3 bug and behavior changes?


Bentley Drake wrote:
> 
> Hi,
> 
> I have some software that is currently using the original Javasoft JAXP
1.1
> reference implementation (downloaded from
> http://java.sun.com/xml/download.html), which uses an older version of the
> Crimson XML parser.  I'm testing upgrading it to Crimson 1.1.3, and am
> seeing the following differences when I run my test cases:
> 
> When I convert the XML from a DOM Document back to a String using code
like
> the following:
> 
>                 XmlDocument doc = //...
> 
>                 doc.getDocumentElement().normalize( );
> 
>                 StringWriter sw = new StringWriter( );
> 
>                 ((XmlDocument)doc).write( sw );
> 
>                 String xmlString = sw.toString( );
> 
> I get additional blank lines between nodes that I didn't have with the
> earlier Crimson library.  I know these don't matter wrt the data, but i'm
> wondering why things changed.

It looks like you are using internal interfaces that are not part of
JAXP 1.1.  This is not recommended.  One place you can look at is the
code in XmlDocumentBuilder.java which builds the nodes of the DOM tree
from SAX events.

> 
> Also, when I attempt to copy an entire Document object using the following
> code:
> 
>         XmlDocument src = //...
> 
>         XmlDocument copy = (XmlDocument)( src.cloneNode( true ) );
> 
> I get the folllowing exception:
> 
> org.apache.crimson.tree.DomEx: HIERARCHY_REQUEST_ERR: This node isn't
> allowed there.
>         at
> org.apache.crimson.tree.XmlDocument.changeNodeOwner(XmlDocument.java:1156)
>         at
> org.apache.crimson.tree.XmlDocument.changeNodeOwner(XmlDocument.java:1177)
>         at
> org.apache.crimson.tree.XmlDocument.cloneNode(XmlDocument.java:1101)
> 
> The associated code in the XmlDocument class, method changeNodeOwner(), is
> the following:
> 
>         //
>         // If node is an attribute, its "scoped" by one element...
>         // and if that scope hasn't been changed (i.e. if this isn't
>         // a recursive call) we can't really fix anything!
>         //
>         if (node instanceof AttributeNode) {
>             AttributeNode       attr = (AttributeNode) node;
>             Element             scope = attr.getOwnerElement();
> 
>             if (scope != null && scope.getOwnerDocument () != this)
>                 throw new DomEx (DomEx.HIERARCHY_REQUEST_ERR);
>         }
> 
> The test-case XML uses attributes similar to those shown in the following
> XML fragment:
> 
>                 <DTSENT type="datetime">
>                         <DATE value="12-12-1998"/>
>                         <TIME value="11:15 PM"/>
>                 </DTSENT>
> 
> The description for the exception from the javadoc is as follows:
> 
> HIERARCHY_REQUEST_ERR
> public static final short HIERARCHY_REQUEST_ERR
>      If any node is inserted somewhere it doesn't belong
> 
> If I already have a Document, and am just cloning the entire document, i'm
> having trouble understanding why this exception is occurring, since
> presumably the source document validates all node insertions as valid, as
> does the target document.
> 
> Prior to the Crimson upgrade, the test cases ran to completion without any
> exceptions. I'd like to upgrade if possible to prepare for the next JDK
> release.
> 
> Any ideas?

No, I'd suggest looking at the source code in org.apache.crimson.tree to
find out.

> 
> Thanks,
> 
> Bentley
> 
> P.S.: Does the current package structure of the library reflect that which
> will be present when JDK 1.4 goes GA?

Current plans are that JDK 1.4 FCS (first customer ship) will have
Crimson 1.1.3 in it.

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org