RE: XML Import/Export To/From FM+SGML (The Link Problem)

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 05:26 PM 9/6/00 -0700, Sylvia wrote:
>Dan, now I'm way confused. Do I understand correctly from this that, in
>fact, Frame+SGML actually is not and will not be a tool that we can use to
>create documents and then convert them to XML? I thought you were saying, in
>your earlier email to me, that it was and we could. Or is it only what you
>were saying to me earlier: that we can use the tool in this way but it
>requires something besides the tool itself--the import/export application
>that you described?
===================================================
As long as you don't intend to use Unicode fonts in FM+SGML (because
you can't), and are mainly using only the Latin-1 (English) character set
(i.e., no Scandinavian, Central European, Cyrillic, or exotic languages), 
you can
successfully originate structured docs in FM+SGML and export them
to Unicoded XML. You cannot, however, round-trip them out to XML
and then back into FM+SGML without doing the tweaking described
in my earlier post.

FM+SGML always requires an import/export application definition to
import and/or export XML or SGML. All of the tools needed to create
such an application definition are built into FM+SGML (i.e., no 3rd-party
plug-ins are needed).

THE LINK PROBLEM
If you use cross-reference or hypertext links in the structured documents
you originate in FM+SGML, they will not be Xlink-compliant when you
export them to XML, and thus will be inoperative in an XML-aware browser.

In HTML, "simple" links are defined with the <A> tag which contains
the cross-reference text. Each such <A>  tag has an href attribute which
contains the link pointer.

In XML, almost any element can also be a link by defining it in the DTD
as having XLink attributes, one of which is the href attribute which contains
XPointer values that differ in form from the link pointer values used in HTML.
These XPointers can have many different forms. XLink attributes include,
in addition to href, xlink:form, content-title, content-role, title, role, 
show,
actuate, and behavior. Your EDD and DTD must declare the XLink attributes
for all elements that are capable of also being links.

XPointers define a much more complex and varied scheme than HTML
for addressing individual parts (i.e., source nodes) within XML documents.
Some types of XPointers require that elements which are capable of
being source nodes must have an ID attribute declared in the DTD/EDD,
but other types do not.

As you can see, things can get quite complicated. Since FM+SGML does not
have the capability to recognize and act upon these Xlinks, clicking on them
in a structured FM+SGML document will not produce any hypertext jump action,
even it the XLink and XPointer are of the most simple type, and points to a 
node
within the same document.

Thus, the Hobson's choice I mentioned in my earlier post. If the
links (e.g., FrameMaker cross-references) work in FM+SGML, then
they won'f work in the exported XML document instances. But if you
set up the links in FM+SGML to be XML-compliant, they won't
work in FM+SGML, thus you cannot, before exporting your documents to XML,
check out the links in FM+SGML to verify that they work, nor is there any
automated way in FM+SGML to find and fix unresolved XLink-compliant links.

It is also apparent that, if you make the links XML-compliant in your
FM+SGML structured documents, then the links will also fail to work if
(as is likely) you also want to export the documents to PDF.

One possible alternative is to use ordinary FrameMaker cross-references (these
cross-references must be in special cross-reference elements) in your
structured FM+SGML documents, which allows you to check that all links are
working before exporting to XML, and to also export to PDF.
Then, one of the followiing solutions would have to be found:

1. Use the FDK to develop an API that converts cross-references to 
XML-compliant
links on export to XML. Perhaps an FDK expert who is reading this could
respond by indicating whether such an API is feasible.

2. After exporting to XML, use some kind of middleware (OmniMark?) to convert
the cross-references to XML-compliant links.

3. A third-party software company could develop an FM+SGML plug-in that
performs the proper link conversions on both export to, and import from, 
XML. This
would be the optimal solution.

If none of these alternatives are feasible, then I conclude  that,
if your documents require links that will work iXML, you probably
need to use an authoring tool other than FM+SGML to originate
them.





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