Access Languages are Tied to Schemas

[Jonathan Robie]

At 04:38 AM 11/21/97 -0800, Mark L. Fussell wrote:
 
>Which would make SGML/XML a presentation model (i.e. similar to a 
>reporting view) on more sophisticated information bases.  This would 
>inherently be worthwhile if it provided a very understandable model to 
>the user: more understandable than the underlying database.  

Precisely. This would be equivalent to defining a "document view" for a
database using a DTD.  

>SGML/XML could provide a very sophisticated version of this "reporting" 
>but I think it could be trapped between the ultra-simple HTML and the 
>more sophisticated information models and would rarely be used outside of 
>niches (just use an HTML builder on top of a database).  So I would 
>rather see SGML/XML go upward and provide a more accessible interface to 
>"complete" information models than stay in the middle.

The ability to define "document views" for external systems is important
whether or not anything more sophisticated is done. I'm not sure exactly
what you mean by "a more accessible interface to 'complete' information
models". Could you spell that out for me? 

I see a big difference between using SGML/XML to create information models
and using SGML/XML to simulate information models that are actually defined
in another paradigm. I think it is important to recognize that the object
oriented model and the SGML/XML document model are significantly different.
SGML/XML can be used as an exchange format or view model for object data,
but it is not an object oriented system. Similarly, SGML/XML can be used as
an exchange format or view model for other kinds of systems, such as
relational databases.

Of course, SGML/XML is a data model in its own right. The data defined by
XL7, for instance, may be defined in documents, but it is the kind of data
traditionally managed in databases, and complex relationships among this
data are possible. I guess what I am saying is that (1) documents are not
just substitutes for objects in object systems, (2) documents can be used to
manage rich data, (3) SGML/XML does not need to be changed into an object
oriented system to make this possible, (4) architectural forms allow great
flexibility in this kind of system.
 
>Actually, I think in concrete terms I would like to be able to change 
>your suggested OQL from: 
>
>    select  e 
>    from    e in SGMLElement,
>            a in e.attributes,
>            s in e.subElements
>    where   e.tagName = "SECT1"
>      and   a.tagName = "ID"
>      and   s.tagName = "PARA";
>
>to something like:
>    select section
>    from   section  in Sections
>           children in section.allChildren
>    where  section.level > 1
>      and  section.title.beginsWith("MONDO")
>      and  children.text.contains("ChiMu")
>
>But still use SGML/XML/OML technology and be working from the same 
>original encoding.

Let me give a little background: the first query is slightly modified from
an actual query for an object oriented database that contains SGML data. The
only modification that I made was to change some of the names of the classes
used to store the data, which is basically like changing the names of the
tables in a relational database. My query assumes that there is not a new
database type or a new table for each element type, but that the data model
for the relational or object oriented database is quite simple, representing
elements, their children, and their attributes. In an object oriented
database, your query would require that each element type be registered as a
separate class in the class dictionary for the database. I think that it
will probably be easier to implement queries of the first kind in existing
object-oriented and object-relational databases.

But I think we are pretty much in agreement that full-text and other text
operators would be useful, that boolean operators are important (as well as
precedence), that path expressions of some kind are important to allow
queries to utilize the structure of SGML containment (and, if possible,
references), etc.

Jonathan

Jonathan Robie
jonathan at texcel.no
Texcel Research  http://www.texcel.no

 


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)