- From: Borden, Jonathan <jborden@mediaone.net>
- Date: Wed, 6 Jan 1999 10:51:00 -0500
- To: <www-dom@w3.org>
Miles, I agree with you that interface design is an interative process, as is specification design. The question is, for DOM Level 2, what is the set of minimum DTD functionality? I would like to see, as a first step, a set of interfaces that allow inspection and creation (r-w) of the DTD tree. In terms of optimization, mechanisms to extend or version interfaces can provide for additional features, interfaces, behaviors (etc) at future stages... I'm just saying that its hard to run before we walk and waiting for something perfect is an excellent way to wait forever. DTD's are not new, nor are their parsers so I suspect that there exists sufficient expertise to specify reasonably functional interfaces. If this isn't done in the DOM spec, vendors will be forced to provide their own non-standard implementations, such as those that exist for the creation and parsing of XML documents today. This leads to code dependencies. For example, in the two implementations I am most familiar with, MSXML and IBM 4J, MSXML (IE5) because of its XSL support, and IBM 4J because of its open source, XPointer, RDF etc support, both define a set of superset interfaces. This is to be expected. Perhaps we can look to these suprasets for guidance on what ought to be included in the DOM itself to provide more complete functionality. That being said, I'm finding these MS's extensions quite useful in my working programs (e.g. see http://www.xml.com/xml/pub/98/12/consult98a.html ) (JavaScript to follow): var str = DOMNode.transformNode(xslDOMNode); var NodeList = DOMNode1.findNodes( xslSearchString ); var DOMNode2 = DOMNode2.findFirstNode( xslSearchString ); (my 2c) Jonathan Borden JABR Technology Corp. http://jabr.ne.mediaone.net > Jonathan Borden wrote, > > Issues concerning *behavior* of the interfaces should > > wait until the interfaces themselves have been defined. > > Certainly behavior is important for the design of the > > interfaces but, for example, the issues about schemas > > should wait because schemas can already be expressed using > > existing DOM mechanisms. > > > > Suppose we are writing a word processor: is it rational > > to implement the spell checker before the keys are hooked > > up? > > I agree in this particular (ie., DTD) case, but not as a > general rule. > > Interfaces constrain implementations ... a given interface > might make an implementation with properties X, Y, Z > impossible. This has come up wrt the DOM: the way the > NodeList interface was specified makes it very difficult to > put together an implementation with acceptable performance > characteristics. > > Designing interfaces is something that has to be done with > a view to possible implementations ... it's an iterative > process, not a top down one. >
Received on Wednesday, 6 January 1999 10:54:12 UTC