[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
Subject: Re: [FrameSGML] XML import/export to/from FM+SGML
From: Marcus Carr <mrc@xxxxxxxxxxxxxx>
Date: Fri, 31 Mar 2000 11:24:55 +1000
CC: Free Framers <framers@xxxxxxxxx>
Organization: Allette Systems (Australia) Pty Ltd
References: <2.2.16.20000330095557.0fcf4e1e@pop.primenet.com>
Sender: owner-framers@xxxxxxxxx
Dan Emory wrote: > After further analysis, I've concluded that FM+SGML 5.5.6, even with the > addition of the XMLcss.dll plug-in, does not have the capability to properly > export structured documents as well-formed, properly formatted XML that > includes links and cross-references. Nor does it have the capability to > import XML document instances. I surmise that there is nothing in V6.0 that > would alter my conclusion. Here are the problems: > > 1. The XMLcss.dll plug-in produces stylesheets with many formatting anomalies. 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. > 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. > 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? > 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. I'm not convinced that it's not worth creating an XML import, but the loss of the links during export are a show-stopper. I have most of the code for creating an API client that uses OmniMark to support import of XML into FrameMaker+SGML - if Adobe could comment on the viability of preserving links on export and I can get to a point where it still looks worthwhile, I'll put it together and we can all have a look. Any comments? -- 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. **