Re: [FrameSGML] XML Import/Export To/From FM+SGML

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 07:32 PM 9/10/00 -0400, Lee Goldschmidt wrote:

>Being fairly new to the FM + SGML game, I have followed these discussions
>with a great deal  of interest.
>
>With regard to the question of whether
>
>FM+SGML can "export cross-reference links that work to XML,"
>
>I am wondering whether the addition of a tool such as Web Works Publisher -
>either the Standard edition or the Professional edition - changes the
>FM+SGML XML picture.  And if so, how.

Frankly, I'm not sure. Allegedly the WWP professional edition can map elements
in structured docs on export to XML, but its real capabilities for doing this
are both uncertain and quite suspect.

For example, the EDD for a structured doc may have element and attribute 
names which
differ from the names for those same elements and attributes in the 
companion DTD. This
is often done, for instance, when the DTD names for those objects are cryptic,
and using more descriptive names in the EDD can make them more
understandable and recognizable to authors. Also, element naming conventions
for elements and attributes in the EDD may make use of characters that are
forbidden in the concrete syntax.

In these cases, read/write rules in an FM+SGML import/export application
definition make the proper name conversion on both import and export.
Read/write rules also allow elements or attributes to be dropped on import 
or export.
If you look through the Developers Guide, particularly the Read/Write Rules
Reference chapter, you'll see all sots of special rules that afford a vast 
variety
of controls over the import/export process. The possibility that WWP
Professionlal Edition come close to matching these capabilities
almost nil.

Furthermore, it is often necessary to use the FDK to develop APIs in order
to successfully export to SGML or XML. Again, I'm certain  WWP  Pro has
no API development capability that could even come closre to matching
that of the FDK


>Are there any other tools that work well with FM +SGML that help with the
>production of XML (with cross references) using FM+SGML.

In the SGML community, OmniMark is the tool of choice. Potentially, XSL
could be even more powerful. But I cannot conceive of any tool that could
divine what external file a FrameMaker cross-reference is referencing when,
on export to XML, no file is referenced in attributes of the linking element.
Admittedly, the EDD/DTD could add a filename attribute to all elements
that are capable of becoming linking elements, but the value of that
attribute would have to be created in one of the following ways:

1. The user would have to manually enter the value, a chore which would
be not only onerous, but also very prone to error.

2. It might be possible to develop an API  that could extract the filename
from the stored cross-reference information, and insert it as the attribute
value.

Clearly, an API that could do this would be a real boon, and someone
(or some 3rd party software company) ingenious enough to produce a solution
would likely find a large marker for a ready-to-use plug-in. As the XLinks
and XPointer standards evolve, modifications to the plug-in could keep it
tracking with those evolving standards.

The whole reason I initiated this thread was to try and get at least one person
or 3rd-part software company thinking about the business opportunity offered
by fixing this glaring deficiency in FM+SGML. Since it appears unlikely that
Adobe will produce a new major release of FM+SGML (in which this
deficiency is addressed) in the next 2 or 3 years, the opportunity could
definitely be rewarding for anyone who comes up with a marketable
fix.

And that's my real beef with Adobe. They refuse to declare whether
or not they intend to continue upgrading and improving the Frame product line.
The pitiful 6.0 release, the first non-point release of the product in more
than 4 years, is a strong indication that the end of the line has been reached.

If Adobe does intend to put the product line into maintenance mode
(i.e., no more releases), they'd be better off announcing it now. Such an
announcement would unfetter the third-party developer community, who
could jump in with all sorts of plug-ins that either enhance the
product, or fix it's deficiencies, completely certain that a new product
release from Adobe would not wipe out the demand for their products.
Such an outcome might stabilize the installed base (who will continue to order
more licences from Adobe as their needs grow), and could potentially
extend the life of the product almost indefinitely. These added capabilities
might also attract new customers to the product, providing even more
revenue to Adobe, and all of it would be gravy.

Before Adobe took over the product line, Frame Technology
strongly encouraged 3rd-party developers, and even annually produced
a comprehensive book (250+ pages) listing and describing 3rd-party
products that enhanced the product's capabilities. Adobe has never
made any serious attempts to sustain strong 3rd-party support for
Frame products, even though they've actively encouraged 3rd-parties
to enhance the Acrobat product line, even buying an interest in
promising 3rd-party companies.

If Adobe isn't going to support the product, they should, at the very
least, get out of the way.
Now.


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