Re: Having both core access and XML-only access

Mike Champion <mcc@arbortext.com> wrote:
>Overall, it seems like you're asking the DOM to do way too much; [...]
>this as an interesting PRODUCT idea that could be layered on top of the DOM
>[...] it's not clear to me the extent to which XML consumers will be
>concerned about always maintaining the validity of their documents.

It is asking DOM to do a lot.  However, I think there is a need to have
standard interfaces for manipulating XML documents that enforce validity.
The existence of such a need has two dependencies: a need to centrally
enforce validity, and a need for the mechanism to be a standard.

You suggest that most applications will be working with well-formed but
not valid XML documents.  I think that will be true, especially considering
that a well-formed document must contain a DTD.  Most applications will be
consumers of XML documents, where the consumer must assume that the
document is valid in order to use it.  However, I also think that there
will be many applications producing XML documents, although I'm guessing
that few of them will change existing documents (they will produced new
documents from scratch).  Any time two applications need to communicate,
they may choose to do so using an extensible future-proof protocol.  One
application will have to create an XML document that is valid with respect
to the receiving application's DTD (otherwise the receiving application
will choke on the document).  The DTD serves as a contract, and the
application that creates a document will need to create the document with
respect to the contract.  Furthermore, the application may want to ship a
DOCTYPE section with the XML document so that the document references the
DTD on which it was generated.  A recipient might be able to then decide
whether it can handle documents of that particular DTD.

I also think the interface to the XML document ought to be a standard.
That way different vendor implementation can be interchanged.  Moreover,
it creates opportunity for document-clients to be connected with different
kinds of document sources.  Some of those document sources might represent
the document using DOM core or XML, while some will have special document
engines.  By having a standard interface to XML documents (which make the
documents look like XML and not something more flexible), we create an
industry for a variety of XML document sources.

>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. [...]

In many cases I do expect DTDs to be in flux, but in many cases I also
expect to see them so rigid that it takes hundreds of thousands of dollars
and a lot of time to get one changed.  I'm referring to DTD standards for
electronic commerce and application interchange.  I'd guess that it will
take many people mulling over DTDs for a long time to solidfy a particular
DTD standard, and then afterwards it would take a lot to get one changed.

However, I wonder if the only real benefit of a validating XML layer is
really just the fact that it validates.  I'm not familiar enough with HTML
to tackle this question properly, but here's the question: Is it possible
to create a DOM document that can be expressed as a proper HTML document
but that cannot be expressed as a well-formed XML document?  Are there any
constraints that are specific to XML that cannot be applied to documents
in general, but that are not embodied in the definition of XML document
validity?  Or is this one of the challenges of the DOM group: to create a
modelling language such that every document expressed in that language has
some well-formed (or proper) expression in all markup languages?

>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 ;~).

I guess I am getting a bit ahead of things.  I would like a better
understanding of what DOM is now and where it is going.  You have
partitioned the effort into various stages, and I'm trying to get a grip
on the roles that have been assigned to the stages.  I'm starting to
understand what the DOM core means to accomplish and what it means to
leave to other extensions.  Thanks for your help in this regard.
--
Joe Lapp (Java Apps Developer/Consultant)
Unite for Java! - http://www.javalobby.org
jlapp@acm.org

Received on Thursday, 4 December 1997 13:05:42 UTC