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

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

Dan Emory wrote:

> I prefer to think it should be able to generate pure data, but also fully
> formatted XML for browser viewing.

That's a natural trap as one legitimate use of XML is browsing, but unlike HTML,
it's not the only use. I don't believe that Adobe should have released the CSS
generator as part of the "XML export", as it too narrowly suggests that the primary
purpose of XML is to make data browsable. I believe that the main thrust of XML is
directed toward B2B, B2C, etc - I have no proof, but offer the various XML lists as
anecdotal evidence.

Although browsing may be one reason that you create XML documents out of
FrameMaker+SGML, I would generally expect the exported XML to be integrated with a
larger set of documents/applications prior to being sent to a browser. Under those
circumstances, generating the CSS with the XML is a furphy.

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

But XML isn't aware of things like browser compatibility, so loading the
responsibility of replacing HTML is unfair, I believe. You could take that even
further and say that issues like splitting levels may depend on whether the data is
being used on the internet or an intranet. The concepts of the separation of
structure and content remain relevant, even though XML tends to blur the need for
the distinction.

> Marcus: You'd probably have a better chance than I of getting a response
> from Adobe.

Ah, you catch more flies with honey...
(I'm well aware of what other things attract flies - no suggestions please.:-)

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

Sure, that would be one solution, though OmniMark is generally accepted as being
more powerful than XSL for some tasks, particularly related to transformation. It
has been developed over about a thirteen year period, principally to perform
translations, with or without structured data.


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



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