Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Dropping subclass checking

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: Wolfgang Hoschek <whoschek AT lbl.gov>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Dropping subclass checking
  • Date: Tue, 17 Feb 2004 23:23:58 -0500

At 5:43 PM -0800 2/17/04, Wolfgang Hoschek wrote:

ParentNode.checkInsertChild
ParentNode.checkRemoveChild
Element.checkAddAttribute
Element.checkRemoveAttribute
Element.checkAddNamespaceDeclaration
Element.checkRemoveNamespaceDeclaration
Element.checkLocalName
Attribute.checkLocalName
Attribute.checkNamespace
Element.checkNamespacePrefix
Element.checkNamespaceURI
Element.checkAddNamespaceDeclaration
Element.checkAddAttribute
Node.checkDetach
DocType.checkPublicID
DocType.checkSystemID
Document.checkRoot
DocType.checkRootElementName
ProcessingInstruction.checkTarget
Attribute.checkType
{Attribute,Comment,ProcessingInstruction,Text}.checkValue
(Search for methods matching "check*")

I'm mulling over whether checkDetach() and checkRemoveChild() can be combined, Otherwise, I'm fairly fond of them. It's not just that they allow subclasses to add constraints. They let subclasses hook into and monitor essentially any operation of interest. For instance, if a document were being logged to a database, every time the document was modified, you could use these methods to capture and log that change.

It is a big batch of methods I admit, but they are protected so they're fairly obviously distinguished from the basic public methods.

Similarly, there is no real need for "somewhat atomic" inserts/removes as seem to be currently shaping up in CVS. They are nice goodies, but introduce complexity for little real benefit. My take is that usecases are not particularly convincing and that it looks a little like a solution searching for a problem.

Glad to know someone's watching CVS. :-) They're no longer somewhat atomic. They are atomic. The complexity is all in the internals. It has little if any affect on the public API. In general, I think this is a good thing. I think it's good for removeChildren() and replaceChild() to either succeed or fail without changing anything. Failing halfway through is too unpredictable. If anyone else notices any non-atomic core operations, please let me know, though I think these too are the major ones.

--

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




Archive powered by MHonArc 2.6.24.

Top of Page