Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Attribute type CDATA vs. UNDECLARED: how to treat them as equal if they are equal?

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • To: Christoph LANGE <ch.lange AT jacobs-university.de>
  • Cc: Normen Müller <n.mueller AT jacobs-university.de>, xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Attribute type CDATA vs. UNDECLARED: how to treat them as equal if they are equal?
  • Date: Thu, 17 Jan 2008 07:30:39 -0500

Christoph LANGE wrote:
Dear XOM developers,

in Attribute.Type, the values CDATA and UNDECLARED are distinguished -- a feature that causes a bug in our application. The bug occurs in a situation where some documents are originally accessed via DOM (and then converted to XOM), and others are originally accessed via XOM. In the document from the DOM source (parsed using the default DocumentBuilderFactory of Java 1.5) and in the document from the XOM source (parsed using the default builder of XOM 1.2b2), there are two attributes with an identical XML representation. The one from the DOM source gets an Attribute.Type of UNDECLARED, whereas the other one is recognized as CDATA, which ultimately makes them unequal according to the equals() method.

In our application (the pattern matching of the mmlproc math renderer developed by Normen Müller (Cc); see http://kwarc.info/projects/mmlkit/), we have so far compared attributes by comparing local name, prefix, type, and value. Could you give a recommendation how we should compare instead? Just ignoring the type, if one of the two types to be compared is UNDECLARED?


Let me think about this one. What equals method are you using? XOM's equals method always compares nodes for identity. Two different attributes are never equal regardless of type. Could your code simply compare the values of the attributes instead of the attributes themselves?

The critical difference, if I recall correctly, is that "If the attribute type is not CDATA, then the XML processor MUST further process the normalized attribute value by discarding any leading and trailing space (#x20) characters, and by replacing sequences of space (#x20) characters by a single space (#x20) character."

"All attributes for which no declaration has been read SHOULD be treated by a non-validating processor as if declared CDATA." but apparently a validating processor should not treat such attributes as CDATA (or is that a spec bug?)

I know I had a reason for distinguishing undeclared attributes. Right now I just can't remember exactly what it was. Let me look at the code. Hmm, nothing obvious there.


--
Elliotte Rusty Harold elharo AT metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/




Archive powered by MHonArc 2.6.24.

Top of Page