🚀 go-pugleaf

But support for queries of the form "move to previous <item> element"
would be difficult to support without storing the entire database in
fully parsed form.  Then you're not really talking about SGML at
all, you're talking about a hierarchical database, object-oriented even,
with facilities for SGML import and export.

In fact thinking of this as SGML could raise many problems, for example
forcing users to make distinctions between element-attributes and element
data, and forcing them to know about ordering even when (to the data) it
might not be significant.  To me, choosing whether to store data in
content or attributes is one of the real hassles of DTD design.  Surely
the way to go is define a common view of object-oriented databases, and
then settle on a way in which these can be imported and exported as SGML.

One useful thing to do might be to build SGML support into one of the
string-processing languages like SNOBOL or Icon.  (I don't really class
Rexx or Perl since they only have linear patterns, but I do know of some
database query languages which work on the SNOBOL model.)