Re: Reading the runes

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 10:44 AM 11/2/00 -0500, Larry Kollar wrote:
>Warning... rank speculation on details follows....
>
>I suspect that Adobe will add export filters (or in the case of
>Frame, a WWP project) to their products.
>These filters/projects
>would write XML that conforms to one or more well-defined XML DTDs.
====================================================
Not good enough. Standardization on a few DTDs is precisely the wrong
direction. XML is intended to facilitate all types of information interchange,
and different business/discipline types will develop their own DTDs for
that purpose. There will be an explosion of DTDs, hence the approach
you describe will always lag behind.

Not only that, but you do not mention the requirement for importing, as
well as exporting, XML. The most likely scenario is that authoring
will (usually) take place in WYSIWYG DTPs, but the exported XML
is parsed into its constituent elements and stored in a database,
where change control/revision tracking. check-in/check-out, and
other similar functions are managed. Consequently, the authoring
software must also have the full capability to import XML. This
approach greatly facilitates information reuse and repurposing,
as well as collaborative authoring. Authors can search for and
retrieve into their DTP from the database only that information
which must be reused, repurposed, or changed. When information
must be revised, the author doesn't have to check out an entire
document. Instead (s)he checks out only the chunk that needs
changing, which remains locked until the revised version is
checked back in. This allows revision tracking to any level of
granularity, and also permits many authors to work simultaneously
and without conflict on the same document.

Converting unstructured Frame docs to XML via paragraph-tag-mapping
algorithms is not a workable solution, because it relies for its success
on consistent tagging, no format overrides, and the use of the
correct para or character tag for each structural component in each of its
possible contexts within the unstructured doc. We all know
those requirements are rarely, if ever, met. That is particularly true
in the case of legacy documents created at a time when the future
need for rigorous and consistent tagging was ignored or unrecognized.
Yet, the ideal solution is to convert valuable legacy documents to
XML for archival storage in a database, where they can be managed,
and made available for information reuse.

Moreover, the limitations of the tag mapping approach precludes
the important ability to add metadata, in the form of attribute
values, as well as the ability to export complex multi-level
structure that is beyond the capabilities of the tag mapping approach.

The only Frame product capable of delivering what is described in
Adobe's press release at:

http://www.adobe.com/aboutadobe/pressroom/pressreleases/200010/20001031netvi 
sion.html

is FrameMaker+SGML. But that product
needs extensive enhancements, including:

+ The full capability to import, as well as export, XML. On import,
     it should be possible for FM+SGML to recognize the DTD
     declared in the XML document, and select the appropriate
     import/export application definition (including the EDD/template) to
     be used for the import process.

+ A full implementation of Unicode, not only for import/export but
    also internally. This allows the use of multi-language Unicode-
    compliant fonts for both authoring and translations.

+ Major improvement in the capabilities of read/write rules so as
    to avoid the necessity of API development in all but the most
    exotic cases.

+ A full implementation of XLinks and XPointers for hyperlinks
    as well as for internal and external cross-references, such that
    those links will work internally within FM+SGML, and will
    also be kept intact and working on both import and export.
++++++++++++++++++++++++++++++++++++++++++
>And (here's where the partnerships come in) various presentation
>devices would extract only the info that it can use -- for example,
>a WML cell phone would ignore graphic or video media (although it
>might attempt to extract a sound track) -- and present it in a
>manner best suited to its abilities.
===========================================
XSLT (XSL transformations), which is part of the XML standard set,
is intended to do what you describe above.

XSLT middleware can not only convert XML instances to the DTD
required by the end user, it can also extract only the information
that can be used, and format it to fit the individual end user's needs.

When you read through the press release, you're forced to conclude
that, in essence, Adobe's vision now includes its commitment to XML,
But until Adobe issues a press release explaining in detail how it
intends to implement what its "vision" is, particularly as it relates
to FM+SGML, I remain skeptical.




====================
| 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.   **