Re: XML when? and the three-shell trick

[hedley_finger@xxxxxxxxxxx]

All:

We need not let our hearts bleed for Adobe's probable future tribulations
in incorporating Unicode in FrameMaker+SGML.  This is an issue completely
distinct from XML.  All the products -- InDesign, PageMaker, GoLive,
Illustrator, FrameMaker, FrameMaker+SGML -- are going to HAVE to support
Unicode, unless Adobe is thinking of not going into, say, the China market.

While it is a considerable task to implement the entire XML standard, it is
a comparitively small step to move from XML to "XSGML" on the same model as
"XHTML".  That is, a subset which is fully conformant with the complete
standard in that it doesn't break any rules.  Of course, FM+XSGML could not
import any arbitrary XML document.  But it should at least be able to
export a subset XML document and re-import it.  Since the XML subset
document would not break any XML rules, it would then be compatible with
other systems for further processing, e.g. personalized page serving.

While Unicode is certainly a long-term requirement, the substantial
English-speaking market, and markets using the roman alphabet as supported
by FrameMaker's current language dictionaries and character mappings, could
benefit from a v.6.5 release or whatever of FM+XSGML.  This interim release
could help fund the ongoing development effort for full singing and dancing
schemas, entities, Unicode, XSL, etc.

I am reluctantly coming to the conclusion that company is likely to dump
the FrameMaker-to-FrameMaker+SGML migration path to XML unless Adobe can
come up with a more convincing case than their "network publishing" spin.

Now for the three-shell trick ...

Have you noticed that most of the improvements to FrameMaker since v. 4.0
have had to do with usability?  That is, changes to the GUI and convenience
functions (e.g. renaming files in the book window).  BUT there has been
scarcely any change at all in the underlying document model (except for
<$chapnum> and other minor improvements, etc.).  These changes are very
cheap since they rely on the current API; for proof, most of them could
have been programmed in FrameScript.

Adobe can only go so far with these cheap changes to the GUI and expect us
to continue paying steep upgrade prices for cosmetic improvements.  (But
how about Normal, Page, and Outline view with, for the last, drag-and-drop
restructuring, sorting, promotion, demotion, etc. like Enhance?)

So let's hear it for document model improvements ...

@    ANDing conditional tags, not ORing them as at present
@    footnotes breaking across pages (keep ye the faith, O Graeme Forbes)
@    context-sensitive master page application
@    working in double-spreads (e.g. a graphic across facing pages)
@    chapter notes and end notes
@    glossary synchronization and sorting
@    chapter TOCs
@    figure elements consisting of grouped title, caption, anchored frame,
notes (like a one-celled table)
@    better autolayout when reflowing: a hierarchy of possible table and
figure placements, rather than choosing between ONE of float, anywhere, top
of column, etc.
@    index cleanup (inserting continuation lines, smart column breaks,
merging a single sub-entry into its parent entry, etc.)
@    TOC/LOF/LOT cleanup (smart column breaks)
@    <insert your favourite RFE>

Regards,
Hedley

--
Hedley Finger
Technical Communications/Technical communicator and FrameMaker mentor
MYOB Australia <http://www.myob.com.au/>
P.O. box 371   Blackburn VIC 3130   Australia
12 Wesley Court   Tally Ho Business Park   East Burwood VIC 3151
Australia
<mailto:hedley_finger@myob.com.au>
Tel. +61 3 9222 9992 x 7421
Mob. +61 412 461 558


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