>Interesting, I see that cloning of DocumentType, Entity, and Notation nodes >is also implementation-dependent.
Yep -- because (and for the same reasons that) there weren't createDocumentType/createEntity/createNotation methods in DOM Level 1. And the fact that these weren't guaranteed is why cloning Documents was considered questionable. This will probably be reconciled in DOM Level 3, as the Abstract Schema support is introduced. >Doesn't that sort of make the whole thing implementation-dependent The main document content -- the root element and its descendents, plus top-level comments and PIs -- is guaranteed to be clonable. DTD-specific material isn't, at this time. >What's the purpose of having an interface which >allows cloning, if it requires knowledge of the implementation? The interface is intended for the nodes it explicitly supports, and if you use it for those it's guaranteed to work. The DOM WG chose not to explicitly forbid it for the DTD subtree, while warning folks not to rely on that to be portable. The alternative would have been to say that trying it throws an exception, which would prevent compliant implementations of the DOM from adding that capability as a custom extension; instead, they'd have to invent a new method which could handle these. Sometimes, leaving something as unsupported but not forbidden is a reasonable compromise. This strikes me as one such case. But of course I was on the DOM WG for a while myself, so feel free to take my point of view with the appropriate-sized serving of salt. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
