Re: FrameMaker 5.5.6 and XML experience?

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 12:15 PM 10/25/98 +1100, Marcus Carr wrote:
>Dan Emory wrote:
>
>> The HTML-like solution offerred in FM5.5.6 will be a loser. The
>> question is what about the "real" XML implementation in FM+SGML 5.5.6,
>>
>> which, if it was done right, should avoid all those shortcomings? Has
>> anyone
>> explored it yet? Is it viable?
>
>As I mentioned in my last post related to Frame's XML ability, I haven't
>had much of a chance to play with it, but what I saw looked pretty good.
*************************************************************************
I was talking about the fact that, as many have stated in postings to the
list, Frame's HTML converter leaves much to be desired, and presumably those
same shortcomings would exist (and perhaps even be compounded) when
attempting to convert unstructured Frame documents to XML using the tag
mapping approach. Most people who are serious about HTML have gone to
Quadralay Webwork Publisher because it is far superior to FrameMaker's.
************************************************************************
>I'd be interested to hear what you mean by "real" and what shortcomings
>you're aware of.
************************************************************************
A "real" solution should be the one offered by FM+SGML 5.5.6, which should
allow us to create structured SGML/XML documents that can be exported as
conformant XML without any necessity for the kind of tag mapping required
for converting unstructured documents. Producing XML-conformant output from
a structured document is certainly more "real" than producing it from
unstructured documents. Also, how could the HTML-like conversion of
unstructured documents deal with attributes? If it can't, then you lose one
of the major advantages of XML, namely the use of attributes to facilitate
information searches and other functions (e.g., formatting the output for
viewing).
******************************************************************************
>Are you implying that Frame should produce a DTD for
>the files saved as XML?
*****************************************************************
No, but an application pack from Adobe that includes a DTD, EDD, and
read/write rules would be a nice kick-start for those venturing into XML.
***********************************************************************
It seems to me that an approach similar to the
>one that is employed for producing HTML would be quite reasonable.
>It seems to me when you already have the high-end solution well covered,
>you might be wise to cater to those seeking the lowest common
>denominator solution. Given Frame's ability to deal well with highly
>structured data in the form of SGML, I would have thought that the
>creation of simple, well-formed XML would be the logical other end of
>the market.
>Having been involved for many years with the conversion of
>legacy data, I wish all word processors were capable of producing just
>such a thing - it would cut out the ugliest and most time-consuming step
>of the conversion cycle.
*****************************************************************
I thoroughly agree. The trouble is successful, trouble-free conversion
requires that the unstructured source document be consistently and
rigorously tagged, something that is, unfortunately, quite rare. Even if a
document is consistently tagged, the tagging scheme must be designed to
facilitate successful conversion, and often that is not the case. The result
is that considerable post-conversion rework is usually required.

Having to go through that re-conversion and rework process each time an
unstructured source document is revised is highly inefficient, and makes no
sense.

Hence, I argue that the high-end solution, where all documents are authored,
maintained, and archived as metadata-enriched (metadata in the form of
attributes) structured documents is the only solution that makes sense.
That's what I meant by "real".

Dan Emory
Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design
and Database Publishing Specialists

Voice/Fax: 949-722-8971
E-Mail: danemory@primenet.com
10044 Adams Ave. #208
Huntington Beach, CA 92646


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