- From: K. Ari Krupnikov <ari@iln.net>
- Date: Thu, 21 Sep 2000 16:42:16 -0700
- To: www-dom@w3.org
Joseph Kesselman/Watson/IBM wrote: > In that case, your documents will never contain a PI initially. If the user > is permitted to create and insert one, you need to find a way to represent > that. If they aren't permiitted to do so, you aren't a fully compliant DOM. > Which one makes more sense depends on what your users will demand. > > If you really want a DOM-like interface on this data structure, it sounds > to me like this should be described as a subclassed DOM with additional > behaviors superimposed, rather than a fully compliant DOM. DOM-like, > DOM-compatable within very specific limits, but not a general-purpose DOM > per se -- because you explicitlyi do not want to permit all forms of > editing on this "document". For read access, this pseudo-DOM needs to appear as a DOM; accessing code should not be required to make any assumptions about compatibility. For example, an XPath search should be possible with standard XPath tools (like org.apache.xalan.xpath). On the other hand, code that modifies the data will have to be aware of the special structure imposed on the document. However, it should not be concerned with the specifics of possible exceptions, because it shouldn't care what physical system is used to store the data. > The spec for createProcessingInstruction says "NOT_SUPPORTED_ERR: Raised if > this document is an HTML document." It doesn't specify what's done if > someone implements a Core DOM with _neither_ the HTML or Extended > modules... Do you think it is an issue worth considering, in light of the rec's suggestion for "veneer" implementations (1.1.2 Memory Management)? Ari Krupnikov
Received on Thursday, 21 September 2000 19:42:40 UTC