W3C home > Mailing lists > Public > www-dom@w3.org > January to March 1999

RE: Level 2 - DTDs?

From: Borden, Jonathan <jborden@mediaone.net>
Date: Wed, 6 Jan 1999 10:51:00 -0500
To: <www-dom@w3.org>
Message-ID: <000001be398c$5b4fe580$d3228018@jabr.ne.mediaone.net>

	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.

> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:05 UTC