Re: Having both core access and XML-only access

At 10:31 AM 12/4/97 -0500, Joe Lapp wrote:
>So, it seems to me that we can have our cake and eat it too.  We can
>have DOM interfaces that will function on well-formed but invalid XML
>documents (for example), and we can have DOM interfaces that only
>operate on valid XML documents.  The first use of DOM will allow us
>to create editor-like applications, and the second use of DOM will
>allow us to create robust distributed applications, where responsibility
>for ensuring the integrity of documents can be centrally maintained.
>Moreover, by introducing transactions into the DOM XML interfaces, we
>minimize the penalties of validity checking and ensure that DOM can
>evolve gracefully in step with changes in the XML specification.

Overall, it seems like you're asking the DOM to do way too much; it is
intended to allow standard access to common functionality, not dictate
functionality that is at or beyond the state of the art. Again, I see all
this as an interesting PRODUCT idea that could be layered on top of the DOM
and would probably find a significant customer base.  But putting it in the
DOM means that we more or less insist that DOM-compliant applications
(including browsers, publishing applications, etc.) implement all that
stuff that is sure to be of interest only to a fairly small subset of DOM
consumers.  

Also, it's not clear to me the extent to which XML consumers will be
concerned about always maintaining the validity of their documents.  In
XML, DTD's are optional, and even when they are in use I suspect that they
will be in flux most of the time, so insisting on maintaining validity all
the time will seriously inconvenience most users. So I don't think that the
behavior you describe should be the default even if acceptance,
implementation, performance, etc. were not at issue.  There will clearly be
a significant demand for "robust distributed applications, where
responsibility for ensuring the integrity of documents can be centrally
maintained", but I see them as non-trivial applications of the DOM, not
something that the DOM should expect to see in a compliant implementation.

I'm intrigued by the transaction processing ideas you put forth.  We will
be considering such features down the road (Level 3 maybe?). It may well be
useful to  consider your idea of a "robust distributed validating XML
application" built on the DOM as a "reference application"  that the DOM
should support in principle, and make sure that the ultimate DOM
transaction model supports the kind of design you propose.  But the DOM is
just learning how to walk; your ideas seem to require it to run, so I think
we'll just have to revisit them when the little guy is more steady on his
feet ;~).

Thanks for such a detailed suggestion,

Mike Champion

Received on Thursday, 4 December 1997 11:21:13 UTC