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