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

Elliotte Rusty Harold elharo at metalab.unc.edu
Thu Jan 17 07:30:39 EST 2008


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/


More information about the XOM-interest mailing list