Three Access Language Paradigms

[Derek Denny-Brown]

At 03:14 PM 11/18/97 -0500, Joe Lapp wrote:
>We would like clients to be able to remotely manage documents
>residing on servers.  Clients need to be able to both query
>and edit those documents.

and later,

>This approach is based on a different way of thinking about
>documents.  Instead of asking document repositories to look
>like XML documents to the external world, we only ask that
>the repositories speak XML with the external world.  DTDs
>would be defined for the protocols that repositories might
>care to speak.  The DTDs would define the structure of the
>protocol messages rather than the structures of documents.
>One repository might speak several protocols (e.g. 'Patient
>Records Protocol V.152' or 'Bank Transaction Protocol 2A').
>If the repository were capable of containing arbitrary XML
>documents, the repository might speak a specific protocol
>called 'XML Document Protocol V.1.0'.

I am not sure that the term "document" is clearly defined for your usage.
The problem I see is that a user might change a "Document" which then
affects a number of other "Documents" because they are all just abstracted
views of a database.  This breaks my own intuitive definition of "document"
which I would normally use to interpret your first statement.  There are no
"Documents residing on servers", but only documents which are generated as
part of a interchange protocol.  Or do you mean that there are documents
(A) (which may not be XML) and then there are XML "documents" (B) which are
generated as part of the protocol to interchange the documents (A)?


I am in complete agreement about the use of XML for information
interchange.  XML  helps solve a number of the problems which CORBA users
are facing currently, esp. in situations demanding high levels of
information content in each query.  CORBA is great for a simple (to
formulate & express) query which a server has to think hard about and can
eventually deliver a simple (to express) answer.  XML is excelent for
situations where either the query or the responce is not so easily
simplified, and structured data interchange is desired.  An example I have
worked on is that we have a java applet which presents an expandable tree
view of some data.  The full tree is _very_ large, and the network
connection may not be fast, so we deliver segments of the tree, using XML,
to the applet, as requested.  Thus the user does not need to wait for
information they do not need.  In a production system the server could
analyse the network connection to determine aproximate-optimal packet
sizes.  CORBA is horrible for this type of thing, relative to our
implementation, since we can deliver N nodes of a tree-graph in one network
transaction, while CORBA would require 1 transactions for each node.  (yes
there are work-arounds, but the XML solution is the simples, and most
versatile I have seen yet.)

Another thing which XML solves when used as a protocol is the problem of
adding information to an existing protocol without breaking existing
implementations.  This is a serious concern.  Try and load a Word97
document into Word95 and you will have a number of problems.  Same with
different versions of PDF.  With NAMESPACES, or some carefull DTD and
implementation design, it is possible to use XML so that this is no longer
a problem.  For example, you have a NAME field, which is currently
interchanged via a NAME element like this:

<!ELEMENT NAME - - #PCDATA>

If the implementations are designed to ignore unknown element tags, then
you might have (in the next version of the protocol)

<!ELEMENT NAME - - ((FNAME, LNAME) | #PCDATA)>
<!ELEMENT FNAME - - #PCDATA>
<!ELEMENT LNAME - - #PCDATA>

which can handle to the old protocol format, and a new format with more
"meta-info".  This strongly appeals to me, since this not only applies to
protocols but configuration info, etc.. the applications are virtually
unlimited.  Suddenly I can share information amonst tools without having to
succumb to the least-common-denominator problem.  With regard to the
protocol issue, we now have a MIME-ish thing with extensibility!  


So the point of my responce, is that some of the ideas in your original
most strike a significant cord with my own ideas, but that the language for
a discussion of these topics is not clear.

There is also an problem that the real requirments for what you (Joe) are
trying to do are extremely fuzzy at this point.  A clearer language for
talking about this is needed (clarify some terms) and the requirements of
what you are trying to do need to be specified more clearly.



-derek

     Derek E. Denny-Brown II      ||   ddb at criinc.com
     "Reality is that which,      ||   Seattle, WA USA
  when you stop believing in it,  ||  WWW/SGML/HyTime/XML
 doesn't go away."  -- P. K. Dick || Java/Perl/Scheme/C/C++

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)