Re: Tools question: Scenario for multiple outputs and validation of i nput

[Dan Emory <danemory@xxxxxxxxxxxx>]

Verner Anderson (<verner.andersen@barconet.com>) is evaluating
alternative scenarios for a future he describes as follows:
>Future
>*       Paper manual (via a pdf file)
>*       Online manual in html/XML format on the web
>*       Context-sensitive help in html format
>*       Validation of input via a dtd
>*       Possibly use of meta-information on the web. For example display of
>the online manuals belonging to a specific software
>*       version.
>*       Possibly multiple displays of the same manual. For example extract
>all the procedures in a manual and present them to the user
>
>Which of the below scenarios do you recommend? Or do you have an alternative
>scenario?
>
>1. FM+SGML, XSLT stylesheets and compiler.
>The paper manual will be made by creating a pdf file. The online manuals via
>XSLT stylesheets and the online help via XSLT stylesheets and a help
>compiler.
>Comment: FM+SGML is rather difficult to learn to use. It only supports XML
>via a mapping filter. It is rather expensive.
================================================
No mapping filter is required if your documents are
structured. The same SGML application definition (including a DTD/EDD)
used to create structured documents and export them to
SGML can be used to export to XML. There are, however, problems
with XML export, particularly the fact that external links/cross-reference
don't work, and even internal links/cross-references are non-conformant
with the XLINKS/XPOINTER standards, which are still evolving.
Also the exported cascading stylesheets presently leave much to
be desired.

As far as FM+SGML being hard to use, It's been shown many times
that experienced frame users can adapt to structured document
authoring in about a week, after which their productivity surpasses
what they could do in ordinary FrameMaker, mainly because all
formatting decisions are made by the EDD, thus writers can focus
on content and structure instead of formatting.

Wide variations in formatting for different deliverables are possible
by means of formatting attributes, multiple templates, and even
variations in the same EDD, in which format change lists are
modified to produce different formatting outcomes.

And, of course, FM+SGML is unsurpassed in providing authors with
a WYSIWYG view of what they're producing. That, plus FM+SGML's
interactive structure view, makes it the best in class as an authoring tool
that hides the complexities of XML/SGML from authors.

Another distinct advantage of FM+SGML is its built-in capability to convert
unstructured FrameMaker documents to DTD/EDD-conformant
structured documents, using Structure Rules Tables. This, however,
is not for the weak-at-heart, and a prerequisite for success is that
the unformatted documents be consistently tagged, with no format
overrides.

Frame+SGML also has the distinct advantage of book files, which
assenbles a number of discrete files into a single exportable
XML or SGML document instance, in which each chapter file
becomes an SGML text entity, and all of the links and
cross-references are internal.

You also mention the FM+SGML/Webworks Publisher combination,
and point out some of its major drawbacks. Owing to the current
XML export limitations of FM+SGML, however, WWP PRO is
essential if you're going to produce XML and on-line help derivatives
from structured documents.

Your last alternative is XMETAL (from SoftQuad), where you anticipate exporting
XML to FM+SGML to produce PDFs for paper documents. However,
no existing version of FM+SGML has the capability to successfully import
XML or HTML. You also mention the possibility of direct conversion
from XMETAL to decent-looking, printable PDF with all links intact
and working. In your dreams.

One unique feature of XML is RDFs (Reference Description Frameworks).
RDFs contain description patterns for complete documents, as well
as separately deliverable "chunks" within documents. RDFs
also include a link pointer to the document or "chunk" which the
RDF describes. I discuss the enormous advantage of RDFs in a paper I've written
entitled FrameMaker+SGML Information Design. Go to:

http://www.microtype.com/

Click the Resources link and scroll down to Dan Emory's Articles.
You'll find it there.

Another important feature of XML is Universal Resource Identifiers
(URIs), which replace URLs. Unlike URLs, a URI doesn't have to
be a filename. It can be anything, including an RDF, or an unique database
identifier that specifies where to find, within an XML database
repository, the component or document that is the link source. Thus, if a
user clicks on a link that is external to the document s(he) is
reading, the component or document pointed to by the RDF is retrieved
from the database.

I believe the future is one in which there are no static document
files, and an XML database repository itself holds all information in the
form of discrete components or "chunks", not documents.
That is, the database repository is the sole source of information,
and that information is guaranteed to be current and
accurate. That, combined with the capability to query the database
to find and retrieve the specific information a user is seeking,
is the raison d'etre for all database applications. For the reasons
cited above, it is illogical to contemplate any future other than one
in which most document information comes from databases.

Users issue and refine queries directed at RDFs within the database.
The documents or "chunks" pointed to by the RDFs which meet the
search criteria are retrieved from the database and assembled
for delivery to the requestor. But before actual delivery, the XML
is passed through XSLT middleware, which transforms the XML
to the DTD and/or formatting (even including PDF) specified
by the requestor.

Under this approach, authoring software has the following purposes:
1. To create structured documents with extensive attributes
     that are exportable as well-formed XML (that perhaps conforms to a
     particular "universal" interchange DTD) for input to the database
     repository.That involves originating new documents, as well as
     retrieving and importing whole documents or "chunks" that require
     updating and editing before being returned to the database
     repository as XML. All links/cross-references would point to
     the URIs for RDFs. If the referenced RDF is embedded in the
     document or chunk (i.e., an external link), clicking on the link
     retrieves from the database the link source pointed to by the RDF.

2. To retrieve and import XML from the database for high-end
     formatting (e.g., for output as printed documents or PDF)
     that exceeds the capabilities of the XSLT middleware.

3. To create and update RDFs that are embedded in the
     documents and "chunks" being created or updated.
     Alternatively, the RDFs might be created/updated
     separately within the database repository itself.

Clearly, no existing version of Frame+SGML can meet all
of these requirements. There are many people like you who
are attempting right now to prepare for the future.
If Frame+SGML is going to play a role in the future as I've
described it, Adobe had better get off the dime very soon
and announce whether Frame+SGML V7.0 will meet the
requirements described above.

====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo@omsys.com with "subscribe framers" (no quotes) in the body.



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **