Re: [FrameSGML] XML import/export to/from FM+SGML

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 11:24 AM 3/31/00 +1000, Marcus Carr wrote:
>In my opinion, support for CSS isn't really necessary for an application like
>FrameMaker+SGML and in some ways, its existence clouds the way I would
expect the
>resultant XML to be used. I prefer to think of FrameMaker+SGML as a datasource
>like any other - something that generates data, not formatting. If the XML was
>coming from a database, you would think nothing of applying and XSL stage
>post-extraction - in fact if you're going to a browser you're probably going to
>need to do that anyway regardless of what application created the data. I
suspect
>that CSS support wasn't that difficult and made for a good selling point,
so was
>included. Really, straight up XML is more what I would want out of
>FrameMaker+SGML.
=========================================================
I prefer to think it should be able to generate pure data, but also fully
formatted XML for browser viewing.
+++++++++++++++++++++++++++++++++++++
>
>> 2. Document splitting is not supported (see Restrictions on page 497 of the
>> Developer's Guide).
>
>This falls into the same class for me - I don't expect FrameMaker+SGML to
create
>the equivalent of a web site, I just want XML that I can do something with.
>Splitting is a usage issue - if the data's going to a browser, I may have
reason
>to split and link, but if it's feeding into a database, I certainly don't. The
>selection of an XSL style sheet that uses document() will accomplish this
at the
>time that the data is being used, not when it's being created.
================================================================
I prefer to think that, in addition to all of its database advantages, XML
should be able to replace HTML in conventional web site usage, where
document splitting is important. The much richer structural and formatting
possibilities of XML are the key argument for migrating from XML to HTML in
conventional web site usage.
+++++++++++++++++++++++++++++++++++++
>
>> 3. Hypertext links (including cross-reference links) are not converted (see
>> Restrictions on page 497 of the Developer's Guide).
>
>That's a real problem - have you had any ideas about getting around it? Can
we get
>some comment from Adobe about this?
==============================================
Marcus: You'd probably have a better chance than I of getting a response
from Adobe.
++++++++++++++++++++++
>
>> 4. XML document instances cannot be imported into FM+SGML (see Restrictions
>> on page 497 of the Developer's Guide).
>
>They aren't currently supported, but there's no reason that they can't be
as long
>as FrameMaker+SGML believes that the data is SGML - using an API client, this
>shouldn't be difficult.
=======================================================
Here's a quote from a book entitled "The XML Bible", ISBN 0-7645-3236-7:

"You can use XSL (transformations) to transform XML to an intermediate
format like TeXML, then us additional non-XSL software to that into any
format you want. You can use XSL to transform to or from HTML and SGML that
meets XML's well-formedness rules."

Perhaps, then, the whole solution for round-tripping XML into/out of
FM+SGML, as well as the key step in transforming it to other formats lies
with XSL, if and when a final version of it is adopted.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
     ====================
     | 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.   **