Re: FrameMaker 5.5.6 and XML experience?

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

Dan Emory wrote:

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

There are some different constructs, but they can be handled by loosening the
content model for XML and by modifying the SGML Declaration. XML applications need
to support Unicode, so XML's characters are a superset of SGML's. Documents can
often be processed without loss by either an SGML or XML parser.

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

Good question - can anyone answer this?

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

Search engine optimisation is a long way from my sphere, but I've never heard that
attribute searching was a selling point.

> 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 believe the use of XSL will become the standard means of associating formatting
information with XML documents. By keeping the formatting out of the document, you
facilitate multiple views of the information through an external mechanism, allowing
you to tailor the view to the user.

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

My preferred workflow might be to save the document as XML so I knew that at least
the document was well-formed. Then I'd use OmniMark to glean the desired structure,
either by using the XML tags or pattern matching - at least I would know the
boundaries of in-line and paragraph-type objects, all I'd need to do is figure out
what they really mean. Frame's conversion approaches fall short in my opinion -
after all, it's not really a programming language.

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

It pretty much is. The conversion cycle isn't likely to change (though you might
streamline it through the API). Even still, imagine how easy it would be to get data
between Word and Frame if they pivoted on something more concrete than the RTF
specification. Even unstructured and/or imprecise documents would be more useful if
they shared an open and well defined format.

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

XML isn't just about making valid documents - the idea of well-formedness has a lot
of merit in a lot of situations. For example, if you dump data out of a database as
XML and format it with an XSL stylesheet, you probably don't ever need a DTD.
Similarly, if you could use the same XML and XSL in either Frame or Word, you have
introduced the sort of competition that Frame would love - a chance to go
head-to-head based on the strength of the application. Niether of these scenarios
depend on valid data or a DTD, but both promote the use of structured documents to
the advantage of the user.

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

Can anyone clarify exactly what capability is provided? Sorry for spending so much
of your time in speculation, but I just haven't had a chance to play with it
properly.

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