[
Lists Home |
Date Index |
Thread Index
]
Kinda. %head.misc isn't exactly "syntax free" and the
controls required one to understand what would now
be considered "infoset types". All in all, it made
an SGML designer's job a lot less labor intensive, but
did not liberate one from understanding SGML DTD design.
I'm not sure that is possible then or now.
A market problem of such products is that they can
be used intensively by one or two people in the
organization, but seldom across the enterprise, or
even frequently by the initial users. They are a
great tool for markup consultants who design DTDs
more frequently and may even maintain them for
the buyers.
Yes, when it came out, modular DTDs were THE challenge
because of CALS 28001 being such a monster. Not
being able to do that properly was a problem but also
a DTD design problem in general.
One wonders what happened to the source code. Seems
to be an issue for many products that get a good run
and then fall off the bandwagon. There are at least
two VRML editors for which having the source would
be useful to some people. I do wonder if companies
holding such assets simply put them in vaults and forget
about them, or keep up just enough market smarts to
dust them off and sell them or repurpose them.
len
From: W. Hugh Chatfield I.S.P. [mailto:hchatfield@urbanmarket.com]
Well I know my very first SGML project was the creation of the first version
of the Canadian CALS DTD.
I was coming out of a quarter century of IT work and just starting on a new
career with SGML?in Microstar. I knew systems analysis, design and data
modelling... but did not know SGML DTD syntax very well. The people I was
working with knew a little SGML and the customer knew none.
N&FD allowed you to create a DTD using drag and drop techniques.. and
concentrate entirely on the business task of creating a data model [as
opposed to the technical task of expressing that model formally in some
syntax]. A rectangle was an element, a tilde on the rectangle represented
attributes, connectors showed and/or logic, occurrance symbols could occur
on elements or connectors. Tree could be expanded or contracted. Large
number of reports (including some standard CALS DTD reports) could be
generated automatically if you used the tools to capture the "documentation"
as well. The actual DTD syntax could be genereated with a button push (save
as DTD). Parsing was done with James Clarks SP inside. The N&FD designer
tool was originally meant to be one of a suite of tools to support Computer
Aided Document Engineering (CADE).. an engineering process to deal with the
entire process of delivering information.
The main claim to fame was the ability to "display" and explore the tree
structure without having to know a speck of SGML syntax. As B Harvey
said... absolutely invaluable for presentations and DTD walkthroughs. A
subject matter expert could be shown the basics of the Data Model in a few
minutes be talking and contributing to the design process.
Latest versions supported XML with wizards to go XML <-> SGML.
Announced but unreleased versions supported schemas.
After I left Microstar (by then Open Text) I provided support services for
N&FD until they withdrew the product.
I could produce any screen shot you want. Any particular DTD in mind????
Now I have to admit that for very large complex, and especially very modular
DTDs, N&FD ran into problems... the main one being that it would create one
big DTD from all the pieces... you could not modify such a modular DTD..
although you could at least display it.
|
