[
Lists Home |
Date Index |
Thread Index
]
- From: "Mark L. Fussell" <fussellm@alumni.caltech.edu>
- To: Jonathan Robie <jwrobie@mindspring.com>
- 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@chimu.com
[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@chimu.com 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@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)
|