[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Access Languages are Tied to Schemas

• From: "Mark L. Fussell" <fussellm@a...>
• To: Jonathan Robie <jwrobie@m...>
• Date: Fri, 21 Nov 1997 04:38:25 -0800 (PST)

Jonathan Robie wrote:
> In fact, at this point I am not advocating anything concrete, except 
that I
> think there should be some kind of query language that SGML/XML systems can
> use to access data in foreign systems like relational or object oriented
> databases, and at present, it makes sense to me that such a query language
> should be defined in terms of SGML/XML structure.  And I think that 
SGML/XML
> is probably powerful enough for that - at least, it is if we are using it
> only for retrieval of information, and not for modification of information;
> for instance, everything that is stored in an object oriented database can
> be stored in SGML - the object ids can be turned into IDs, containers 
can be
> expressed either through containment or sets of IDREFs, etc. As long as
> access is read-only, you aren't losing much. 

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.  

One of the nice things about relational databases is the capability of 
defining "views" on the data.  However simple SQL is compared to (say) 
C++, very few end-users can do anything more than a simple join.  After 
that things get a bit murky and even if the query produces results the 
end-user may have no idea (or the wrong idea) of what the answer 
means[1].  There are many examples of this (see C.J. Date's writing 
especially).  But views and reporting tools (and general UI applications) 
come to the rescue and provide a simple useful view of the complexity 
below them.  

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.  By going upward 
it immediately gains the rewards that you mentioned earlier in the week: 
benefiting from the history/mistakes/knowledge of the database 
community.  

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.  

--Mark
mark.fussell@c...

[1] Part of the problem is because SQL is flawed compared to relational 
theory, but it would still be a problem with a better query language.

  i   ChiMu Corporation      Architectures for Information
 h M   info@c...         Object-Oriented Information Systems
C   u    www.chimu.com         Architecture, Frameworks, and Mentoring

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

• Prev by Date: New release of xslj
• Next by Date: Integrity in the Hands of the Client
• Previous by thread: Re: Access Languages are Tied to Schemas
• Next by thread: Re: Access Languages are Tied to Schemas
• Index(es):
  • Date
  • Thread