[jdom-interest] XML equivalence

Neil neil at ipdevco.com
Thu Aug 14 07:49:57 PDT 2003


I was thinking more along the lines of an extendable approach, an abstract
class Equivalance which could be extended to provide various
implementations, such as literal equivalance, normalized text equivalance,
etc.  It seems like equivalance definitions would often differ in only a few
details on specific leaf types in the tree (such as ignoring namespaces,
normalizing text, etc.).  If that's true, then this could provide a
framework in which people only have to implement a minimal amount,
inheriting the rest.
 
The top level class just has to provide one big instanceof conditional and
define the methods for each type, and the rest can be implemented in the
concrete classes.  Or, for the introspection-sensitive, a method could be
implemented in each type (Element, Document, EntityRef, etc.), specifying
the Equivalance to use:
  boolean equivalentTo(Object obj, Equivalance equiv);
 
Optionally, throw in a Filter, for maximum flexibility:
  boolean equivalentTo(Object obj, Equivalance equiv, Filter filter);
 
Then you could define filters for any circumstance: check only the
elements...
  
Is this a work-saver, or just make-work?  Would anybody use this?  Or just
me?  
 
(Actually, I can probably keep doing a string compare of the outputter text,
myself.  But if everybody's doing that, shouldn't there be a method in
Element or Document to do it so we're not duplicating that code all over the
world?  I'm smiling because it's pretty funny if we think its not
respectable enough to go into the API, but we all do it in our products.)
 
Neil

-----Original Message-----
From: Rolf Lear [mailto:rlear at algorithmics.com] 
Sent: Thursday, August 14, 2003 10:03 AM
To: 'Neil'; jdom-interest at jdom.org
Subject: RE: [jdom-interest] XML equivalence



More than anything, I think you will discover that every person will have a
different opinion as to when two elements are "equals"...

Are they equals with the same namespace/name, with "equals" elements in the
content, etc... 

Basically, there are too many ways in which elements can be considered
equals (depends on how you want it to behave for your application). Putting
any one application's specific "equals" code in to the JDom source would
probably be counter-productive.

Rolf 

-----Original Message----- 
From: Neil [mailto:neil at ipdevco.com] 
Sent: Thursday, August 14, 2003 9:56 AM 
To: jdom-interest at jdom.org 
Subject: [jdom-interest] XML equivalence 


When I first read the following in the FAQ, I was a little surprised, 
although it makes perfect sense. 

>Why does equals() only do a == check? 
> 
>In JDOM two objects are only equal if they're the exact same object. This 
lets a call like 
>list.remove(elem) remove only the exact Element passed in, not any element 
that's equivalent. 
>This's a very important distinction. Doing a full equals() on an Element 
would require recursing 
>down the tree, and in general we believe it unlikely you'll want to know if

this element and all 
>its children are equivalent to another one. If you really do want to know 
you can write some 
>comparison code yourself that checks only as much as you want to check 
(maybe the 
>name/namespaces only) instead of doing a full recurse. 
  
However, since I've been using JDOM, I've now twice wanted to be able to do 
true equivalence checking.  I must not be the only one. 

Have any contributors worked on this or are working on this?  Maybe it's 
time for me to do some contributing, but I'm not sure my XML sophistication 
is great enough.  I'm pretty much just a surface level user of XML, though 
I'm experienced with java frameworks and design. 

Any comments? 


Neil Brandt 







_______________________________________________ 
To control your jdom-interest membership: 
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20030814/6bb4380f/attachment.htm


More information about the jdom-interest mailing list