Re: FrameMaker 5.5.6 and XML experience?

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

Dan Emory wrote:

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

Hmm, there could be an element of truth to that - I don't export HTML, so haven't
ever used that facility, but I have seen it frequently discussed. Other than
forcing the user into a wholly structured environment, what option is there
besides some form of mapping? Perhaps the HTML converter has been improved as a
result of the XML implementation - the old half-full or half-empty glass...

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

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.

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

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

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

Again, I wouldn't choose to use Frame as a structured XML editor - I would just
continue with SGML. For money, a dedicated XML editor is a waste of energy when
you can already handle SGML so well - that was one of the driving forces behind
XML, making it easier for vendors to provide tools. I think that approach would be
a step backwards for Adobe. I'd prefer to see them spending their energy on making
sure it doesn't matter what you want to call your structured data until you save
it, and then it's simply a file format.

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

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.

> 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?

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

--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



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