🚀 go-pugleaf

bernd@melon.iss.nus.sg (Bernd Nordhausen) writes:
> I am in the process of writing DTD's for forms, eg. tax forms, application
> forms, etc.  I think SGML is ideal for representing forms as form in SGML 
> will be more structured, and can be better queried. However, there are some 
> interesting questions that arise.

There's a couple of things I'm interested in doing for which structuring
and queryablility would be cool.  I've been reading comp.text.sgml
for some time to get an inkling of how that might be done.

As I understand it, SGML's tagging is not necessarily for laying things
out on a page, though this is one of the uses.  Instead an SGML tag has
whatever meaning the DTD and processing software wishes to assign.

Taking the `forms' example.  A tag might be `<NAME>' and the value at
that tag is the persons name.  Or a purchase requisition form might
have <AMOUNT-REQUIRED> <ITEM-DESCRIPTION> <CATALOG-NUMBER> <UNIT-PRICE>
and <PRICE> tags, with associated values.  Is there a concept wherein
some `tags' have `values'?  Or does a tag only create a context, and the
data within that context is interpreted in a particular way?

In any case it appears that for `querying' type applications the
SGML parser must build up some data structure, and that the application
program must then be able to probe the data structure at its leisure.
For a normal text processing application (SGML -> TeX -> PS conversion)
you can get away with creating and destroying the data structures on
the fly.  But to be consulted at the applications leisure the data
structures must stay around for a long time.

So... Are there any SGML programming toolkits available which allow
for this sort of thing?  Is the ARCSGML/JClark suitable in this way?
(I'm on a small budget)

<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- "As near as I can tell, only selected dinosaur systems that lurk mainly inside
<- the US DoD won't be MIME-capable soon." - Ran Atkinson <atkinson@itd.nrl.navy.mil>