Re: FrameMaker 5.5.6 and XML experience?

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 10:12 AM 10/27/98 +1100, Marcus Carr wrote in my reply to his reply:
>I'm not sure sure I understand - presumably you wouldn't need to do any mapping
>from a structured document, just export as SGML/XML. The ability to save an
SGML
>document as XML exists in the current release, doesn't it? I see the XML
>functionality as being more suited to non-structured documents.
>
******************************************************************
No, of course you don't have to do any tag mapping in that case, but an SGML
document isn't necessarily XML-conformant. The last time I read up on the
XML standard, there were a number of constructs and data types which are
valid in SGML but invalid in XML. Also (I think) there are limitations on
which character sets can be used in XML.
***************************************************************************
>> Producing XML-conformant output from
>> a structured document is certainly more "real" than producing it from
>> unstructured documents.
>
>You imply that you can't save an SGML document as XML. I would prefer to
have SGML
>anyway, but surely the only shortcomings to having well formed XML would be in
>areas like PIC (processing instruction close), the insertion of an XML
declaration
>and possibly the start  tags of empty elements. For the most part, I don't know
>why you would wish to label the data as XML or SGML at this point - I wouldn't
>distinguish it as one or the other until further down-stream, when I needed
it to
>behave like one or the other.
************************************************************************
But it would be better to be able to export a document as either SGML or
conformant XML, with FM+SGML doing the "tidying up" when it's exported as XML.
That's why I was asking whether anyone had tried out FM+SGML 5.5.6's XML
capabilities. How much will FM+SGML 5.5.6 do automatically (e.g., converting
data types), and how much must be done through read/write rule changes, etc?
************************************************************************ 
>
>> 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).
>
>I'm don't know how well it supports attributes, but I disagree that you
lose the
>ability to efficiently search documents as well as the assertion that they
will be
>used for formatting - there are already a couple of XSL processors around.
>
*********************************************************************
I disagree with your disagreement. Searching on attribute values (e.g.,
keywords, information correlations, etc.) can make searches far quicker and
more efficient. I think there's general agreement that this is the one of
the biggest selling points for switching from HTML to XML.

Using attribute values in EDD format rules for producing printed documents
is a common practice, and there's no reason attributes couldn't be used in
the same way to format documents for on-line viewing in XML, which could
become another major advantage of XML over HTML.
**********************************************************************
>> 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.
>
>Not necessarily - we routinely use tools that will turn an RTF document
into valid
>XML. The structure is largely useless, but at least it allows us to begin
>conversion with the aid of a parser, so we can code for something like "element
>para when attribute was-tagged is equal to Normal and previous element is equal
>title". The problem with word processor formats is that formatting boundaries
>often cross, so you get the equivalent of <b><i>some text</b></i>.
Untangling this
>is half of the battle - I'd love to always start from a well formed
document, no
>matter how sparse the useful markup was.
>
***************************************************************************
If you had FM+SGML available, and you wanted to do a one-time conversion to
a structured document where it will then be maintained and updated, you
certainly wouldn't use FrameMaker 5.5.6's tag-mapping XML converter.
Instead, you'd use the more powerful structure rules table approach provided
in FM+SGML!
**********************************************************************
>> 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.
>
>But once it was structured, you'd probably import it into Frame+SGML and
work on
>it there from that point on, wouldn't you?
*******************************************************************
Except I was talking about the case where the document is authored and
maintained as an unstructured FrameMaker document which is converted
periodically to HTML or XML for on-line delivery. That's what's going on now
with most Frame users who convert to HTML. They have to re-convert it to
HYML every time they update the Frame document because they don't have
FNM+SGML. That's what I assumed you were describing as the "low-end" solution.
****************************************************************************
>
>> 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".
>
>If that's what you need, use Frame+SGML - it provides that functionality now. I
>don't understand what additional functionality you expect to get from this
>workflow by calling it XML.
**********************************************************
Of course, that's what I was arguing. Why fool around with the mickey-mouse
tag mapping approach to XML/HTML conversion? Create structured documents
with FM+SGML, and output them as a conformant documents in SGML, XML, or
HTML, or whatever, avoiding all the tag-mapping hassle. If a document
initially exists as an unstructured document, use FM+SGML's structure rules
table approach to permananetly convert it to a structured document, then do
whatever clean-up work is required to make it conformant to the relevant
DTD. Once that is done, you're in business.
***********************************************************
The issue is turning an SGML document prepared with a DTD that doesn't
conform to the XML standard into an XML-conformant (whatever that is at the
moment) output when needed, while still preserving the option to export it
to SGML for archival storage. That's what I was hoping (and still hope)
FM+SGML 5.5.6 would do. If FM+SGML 5.5.6 can't do it, then obviously, we'll
still preserve the documents in SGML, and use something like OmniMark to
convert SGML documents (whenever needed) to conformant XML.

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