XML Import/Export To/From FM+SGML

[Dan Emory <danemory@xxxxxxxxxxxx>]

REVIEW:
As I mentioned in an earlier post, there is no version of
FM+SGML which can successfully import XML document
instances that are not also valid SGML instances which conform
to a declared DOCTYPE that exists in a predefined
DTD, and whose markup style conforms to an SGML Declaration.
Both the DTD and the SGML Declaration must be
specified in an FM+SGML import/export application definition.

STEPS REQUIRED TO CONVERT XML TO SGML INSTANCES:
To make import possible then, you must first convert the
XML instances into valid SGML instances.

Here are the requirements, as I understand them, for
accomplishing that:

1. Since the XML declaration is a processing instruction,
my guess is that FM+SGML would either ignore it, or
embed it as a maker in the imported document instance.
But, if FM+SGML gags on it because it expects a
DOCTYPE declaration to be the first line of the file,
then you'd also have to delete the XML declaration.

2. The XML declaration you give above does not specify
the type of encoding. Thus, by default, this means
that text entity characters are coded in UTF-8 Unicode.
But this means that any upper ASCII characters (i.e., those
above ANSI 127) must be converted to their corresponding
SGML entity references (e.g., &xxx; where xxx is the
entity name) before those characters can be recognized
by FM+SGML on import.

3. The converted SGML instance must include a DOCTYPE declaration,
the instance must fully conform to that doctype, and the
DTD specified in your application definition file must include that doctype.

4. The DTD and/or the converted SGML document instance must
include declarations for all internal and external
entities referenced in the converted SGML document instances.
In the case on non-SGML external entities, either the
DTD or the converted SGML document instance must have the
proper Notation declarations.

5. You must have, as part of the FM+SGML import/export
application, an SGML declaration file whose declarations
are compatible with the markup style in the converted SGML document
instances to be imported.

SUMMARY OF THE REQUIREMENTS:
To import XML instances, you must first convert them into valid
SGML document instances, which requires that:

A. You must have a complete import/export application definition
in your SGML application definition file.

B. The structure of the XML instances must conform to a
DOCTYPE included in the DTD specified in the application definition.

C. You must convert the XML instances to SGML instances by:

	1) Converting upper-ASCII Unicode characters to their
	    corresponding SGML entity references.

	2) Assuring that each converted SGML instance begins with
	    a DOCTYPE declaration.

	3) Including in the application definition an SGML Declaration file
	    that reflects the markup style of the converted SGML document
	    instances.

D. The application definition must also specify an FM+SGML template
for import, and that template must have imported into it the EDD that
is the companion of the DTD specified in the application definition.

E. The application definition must provide a way to identify and
locate all external entities (e.g, graphics) that are declared in the
DTD and/or declared/referenced in the converted SGML instances.


OTHER PROBLEMS:
Problems  1 and 2 below show that FM+SGML's XML export capability
needs major improvements before it is ready for prime time.

Problem 3 indicates that, even after performing all the steps described
above to convert XML instances to SGML, any links in the converted
SGML instances won't work when you import them into FM+SGML.

1. My recollection is that, on export to XML, FM+SGML
does not write out a DOCTYPE declaration, thus if you try to
round-trip FM+SGML-exported XML instances, you'll have
to add the DOCTYPE declaration back in before you can import it.

2. On export to XML, FM+SGML cross-references become invalid links,
because they do not conform to the requirements
of the XLink standard. In fact, I believe that all links that work
in FM+SGML become invalid when they are exported to XML.
This creates a Hobson's choice: Either make the links work in FM+SGML,
in which case they won't work in the exported XML, or make them work
in the exported XML, in which case they won't work in FM+SGML.

3. I should add that, even after all the steps described above are
accomplished, it's extremely unlikely that Xlinks in the converted
SGML document instance will work when the instance is imported
into FM+SGML, because FM+SGML cannot implement links
that conform to the XLink standard.

CONCLUSIONS:
1. FM+SGML could become an excellent tool for originating XML documents,
if it also fully supported Unicode, so that Unicode fonts could be used in the
authoring process. It now appears likely that Adobe never intends to add
Unicode support to the Frame product line.

2. FM+SGML will not be an effective tool for importing XML instances
until it fully supports Unicode on both import and export, and until it can
import XML instances directly without the necessity of first converting
them to SGML,

3. The usefulness of FM+SGML for either originating or importing XML is
further eroded by its inability to successfully round-trip links, and in
particular, cross-reference links.





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