[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: Chris Despopoulos <cud@xxxxxxxxxx>, "FrameSGML List" <FrameSGML@xxxxxxxxxxx>, "Free Framers" <framers@xxxxxxxxx>, "TECHWR-L" <techwr-l@xxxxxxxxxxxxxxxxx>
Subject: XML in FM+SGML (Was Re: Adobe + FrameMaker)
From: Dan Emory <danemory@xxxxxxxxxxxx>
Date: Fri, 26 May 2000 06:34:33 -0700
In-Reply-To: <LYRIS-25280-3835-2000.05.26-00.38.59--danemory#primenet.com@lists.frameusers.com>
References: <LYRIS-24159-3817-2000.05.26-00.00.03--cud#arrakis.es@lists.frameusers.com>
Sender: owner-framers@xxxxxxxxx
At 09:48 AM 5/26/00 +0200, Chris Despopoulos wrote: -------------------------Snip---------------------------------- Quote from a Statement by Mark Hilton at Drupa: > A major role will definitely be played by the > complete implementation of XML > that was especially written in FrameMaker for > Adobe. A survey conducted by > Adobe among more than 100 major customers and more > than 6000 FrameMaker > users swung the decision in its favor. Even if > version 6 still does not have > XML import, Adobe is working on it at full blast. > >More than marketing brochures, XML import will send the >Maker message loud and clear, IMO. All those dreams of >UberPublishing (why do we resort to German?) are within >reach via XML. And Maker can be a part of it. ============================================ Whether this is good news or not depends on whether it means a full XML implementation in FM+SGML or something wimpy that relies on WWP or a similar plug-in in FM. A real implementation must involve exporting XML from structured docs in FM+SGML, and importing XML to create structured docs in FM+SGML.. But much more than round-tripping is involved. If surveys are what drive Adobe to make the right decisions, it's time we let Adobe know what the minimum acceptable requirements are for a usable XML implementation in the next release of FM+SGML.. For starters, I submit my own list of requirements: 1. A sufficient implementation of of the XSL Style Language, including including XSL Style Sheets, formatting objects in the fo namespace, and XSL formatting properties that are represented by attributes. In addition, the capabiliity to generate a CSS from the EDD's format rules should be retained and improved. 2. A sufficient implementation of the XLinks and XPointer languages, most particularly the capability to convert FrameMaker cross- references (both internal and external) into conformant links on export, and the capability to convert such links into cross-references on import. In addition to these simple links, at least a partial implementation of Extended Links is needed, perhaps including out-of-line as well as inline links. Presently, there are 10 attributes associated with Xlinks. They include xlink:form, href, show, actuate, and behavior, steps, title, role, content-title, and content-role. Exactly how much of the XLink language needs to be implemented, and how much of it is still in a state of flux are issues that need more discussion. 3. A full Unicode implementation within FM+SGML is vital. This would allow multi-language Unicode fonts, as well as Unicode fonts for special languages such as Mathematical and Chemical markup, to be utilized when they become available. How about it framers? If we're all concerned about the future of the FrameMaker product line, then we ought to realize that its future can be guaranteed if FM+SGML becomes the killer app for both XML and translations. We need to conduct our own survey, and submit the results to Adobe. It is quite apparent that the paragraph and character tag mapping approach to XML and HTML conversions used by WWP is a messy, inelegant, and unreliable solution that totally relies on rigorous, consistent application of tags, with no formatting overrides--something that is almost impossible to achieve. The solution is FM+SGML, which guarantees consistent tagging throughout. Solutions like WWP need to be replaced by the much more elegant conversion solutions that are possible with FM+SGML. If there is any future for FrameMaker, it will be an FM+SGML future. Let ordinary FrameMaker fall into the maintenance category where it can die a natural death. This would let Adobe focus all its development energies on making FM+SGML into the killer app it can and should become. ==================== | Nullius in Verba | ==================== Dan Emory, Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com 10044 Adams Ave. #208, Huntington Beach, CA 92646 ---Subscribe to the "Free Framers" list by sending a message to majordomo@omsys.com with "subscribe framers" (no quotes) in the body. ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **