XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

At 11:30 AM +0000 11/13/03, Janek Bogucki wrote:

> If you do decide to retain the current approach then I'd suggest 
> changing from using
> IllegalArgumentExceptions to 
> java.util.UnsupportedOperationExceptions in the same way as the JDK
> Collections classes do _and_ document (in Serializer) that setters 
> are optional for subclasses.

I thought about this, but I think IllegalArgumentException is what's 
right here. These operations are not unsupported. You can call them 
with the appropriate values for canonical XML, in which case they 
throw no exceptions. It's only when the argument is illegal, that an 
exception is thrown. That sounds like an IllegalArgumentException to 
me.

I agree with the comments that have been made about the right object 
oriented way to design this. Adding the extra class to the core just 
feels like a very heavy price to pay for such a minor issue. I'd 
almost rather not make CanonicalXMLSerializer a subclass of 
Serializer at all. I could just call it Canonicalizer. Since 
canonicalization doesn't do line wrapping, indenting, encoding 
detection, or use numeric character references, it actually makes 
relatively little use of the internals of Serializer.

Big question: is polymorphism necessary here? That is, is it useful 
to treat an instance of the Serializer subclass as its superclass? 
Will it ever be useful to write a method like this:

public void doSomething(Serializer s, Document doc)

where we do not know what type of Serializer we have? I admit the use 
cases for this escape me. If it is necessary to do this, we're back 
to adding the AbstractSerializer superclass and the 
ConfigurableSerializer subclass and that's just so ugly for the 
common cases.
--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Effective XML (Addison-Wesley, 2003)
  http://www.cafeconleche.org/books/effectivexml
  http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA