xml-dev - Re: Three Access Language Paradigms

[Derek Denny-Brown <ddb@criinc.com>]

At 10:05 PM 11/18/97 -0500, Joe Lapp wrote:
>Derek Denny-Brown <ddb@criinc.com> wrote:
>>I am not sure that the term "document" is clearly defined for your usage.
>
>... in my post I intended the
>word 'document' to mean a single XML file or any system that makes itself
>appear as if it were analogous to an XML file, such as a database that
>exposes DOM IDL :-) interfaces.  That's the meaning I was using, though
>I realize that it's probably not the best definition to work with.

that helps.

>>[...]  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)?
>
>Boy I really was being quite inconsistent.  When I talk about the protocol
>messages being documents I was talking about a single serializable stream
>of well-formed XML.  I guess I really was quite confusing.

this really helps.  (for me at least)

So this gives us two separate issues, which you are talking about.

1) XML used as an interchange abstraction (your discussion of protocols)

2) XML used as a data modeling abstraction (your XML on the server and XML
document query discussions)

Regarding (1)

my last post had a number of my comments on using XML as a foundation for
interchange (i.e. as a layer in a protocol implementation) so I won't go
into it much more, other than to say that I see this as one of XML's
greatest potentials.  One real need though is some good, simple, free
software that people can use to make this easy.  LT-XML is a good step, but
what I think is needed is a GPL version of something similar.  One really
good way to get XML into regular use beyond HTML-NextGeneration would be to
get it into some GNU projects... just my 2 cents...  If I had more time
that I could devote to freeware projects, I would already be working on this.

Regarding (2)

XML with XLL provides all the pieces, but is almost too flexible to be used
as a general purpose data-modelling abstraction.  I think something
somewhere between XML and RDF and Tim Bray's typed data extensions to XML.
The problem is that XML is all about marking up text.  For it to be used as
a general data-modeling tool, you need some further mechanisms to constrain
the actual data/document instances.  With some basic work to add some more
typing information to XML, and place some limits on element content models
for parts of the document which are not really just text streams.

At least in my mind there is a significant difference between:

<PERSON>
 <NOMEN><FNAME>Derek</FNAME>
        <LNAME>Denny-Brown</LNAME>
 </NOMEN>
 <CONTACT><EMAIL>ddb@criinc.com</EMAIL>
          <POSTAL>blah.. blah .blah</POSTAL>
 </CONTACT>
</PERSON>

and

<P><PERSON-INFO refid=ddb><FNAME>Derek</FNAME> 
<LNAME>Denny-Brown</LNAME></PERSON-INFO>
is contactable via email at 
<PERSON-INFO refid=ddb><EMAIL>ddb@criinc.com</EMAIL></PERSON-INFO>
or via the more traditional postal services at
<PERSON-INFO refid=ddb><EMAIL>blah.. blah .blah</EMAIL></PERSON-INFO>
</P>

they contain the same info, but one is a very tightly constrained structure
which enforces some nice rules (like you can have only one current NOMEN,
though it might provide for alternate (non-prefered) NOMENs etc..) while
the second is good for pulling the information to build the first from a
free form document.  The second would be much better if it included the
first and all the PEERSON-INFO blocks were just references to the PERSON
block to pull the appropriate structures.

My general point being that XML is _too_ flexible for use as a general
purpose data modelling tool, without some additional information.  If I
really wanted to use XML as a data modeling tool, I would require all sorts
of data-type meta-info and content modeling constraints to allow XML to be
used as a sort of snapshot of a data-set which stradled the relational and
object oriented data modeling worlds.  Used this way it provides a kind of
object oriented (with some relation capabilities) database view, with
strong support for dynamic quiries. 

Then again if what you are really after is a marked up text stream, then
XML is a better tool than most, if only because so many people seem to like
it.  Java and Microsoft (independently) have helped show the world that
mass marketing and the "boardroom sell" can take something a lot farther
than it might ever have gotten on its own.


-derek


     Derek E. Denny-Brown II      ||   ddb@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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)