Joseph Kesselman wrote: > Making the kidOK table final means that an extended DOM which wants to > add a new node type can't simply override that table; they'd have to > rewrite the code that consults it.. In fact, I do believe that most
Yep! And while we currently don't take advantage of this capability, I can see where others might want to -- assuming they haven't done so already! Let's take an example: say someone thinks that the DOM L3 AS stuff is too heavy weight and just want to encapsulate DTD content models as DOM nodes with the tree (a la TXDocument in XML4J 1.x, 2.x). They would want to create special node types and want an easy way to do that. However, if the kidOK table is made final, then we have forced them to rewrite the entire DOM impl since the basic operations depend on it. Not a good thing for developers. But I can see how this is a problem so I must admit that I'm torn on this one... Is anyone out there doing "weird" things using the Xerces DOM implementation as a basis? I'd like to hear their input before proceeding. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
