questions on XML import
Wim Hooghwinkel (Scriptware)
wimh at scriptware.nl
Wed Apr 12 03:38:29 PDT 2006
Continuing with my legacy XML documents....
If the error : Unknown Char: ※ appears on import, does that mean that FrameMaker can't read the Uncicode character - even if it's available in the rules file as:
entity "#x203B" is fm char "*";
Note: in the XML it is a Japanese asterix.
Met vriendelijke groet / kind regards,
Wim Hooghwinkel wimh at scriptware.nl
DTP and XML Management
Scriptware bv http://www.scriptware.nl
tel : +31 (0)23 548 48 84
fax : +31 (0)23 548 48 85
http://www.scriptware.nl
info at scriptware.nl info at scriptware.nl
-----Oorspronkelijk bericht-----
Van: Lynne A. Price [mailto:lprice at txstruct.com]
Verzonden: woensdag 5 april 2006 17:40
Aan: Wim Hooghwinkel (Scriptware); Framers (E-mail)
Onderwerp: Re: questions on XML export
At 01:27 AM 4/5/2006, Wim Hooghwinkel \(Scriptware\) wrote:
>Just two quick questions (FM 7.x , Windows).
Wim,
Asking the questions may have been quick, but I'm afraid the answers
aren't as quick as you might think. See below!
>1. After exporting to XML the Import of the same document gives validation
>error:
>Message: Notation 'epsi' was referenced but never declared
>Where should this be declared, in the EDD, DTD or Rules file? On export
>FrameMaker generates the notation:
><!-- Begin Document Specific Declarations -->
><!NOTATION epsi PUBLIC "">
The notation should be declared in the DTD; either in the external
subset (the file often referred to as the DTD), or in the internal subset
at the beginning of the document. Given the two lines you quote (the
comment and the notation declaration), FM has done just that on export.
Unless you have removed that line on import, I don't see why you are
getting an error message.
By the way, as I write this, I have no Internet connection and can't
check, but if my memory is correct, XML public identifiers require a system
identifier. Although FM does not report an error given:
<!NOTATION epsi PUBLIC "">
I believe it is incorrect and should be at least:
<!NOTATION epsi PUBLIC "" "">
I suggest you avoid the issue by adding:
<!NOTATION epsi SYSTEM "">
to your DTD.
And here is some relevant background. When you export a document that
uses a notation that is not declared in the DTD, FM generates a notation
declaration such as:
<!NOTATION epsi SYSTEM "">
in the internal subset. Whenever you open an XML document that has notation
or entity declaration sin the internal subset, FM uses a reference page
called Entity Declarations to save enough information to regenerate those
declarations. Information about notation declarations is saved in a
three-column table. The notation name goes in the first column, the public
identifier in the second, and the system identifier in the third. The table
does not distinguish a system identifier that is present but contains no
characters from one that doesn't appear. When both columns 2 and 3 are
empty, it generates a public identifier, so the imported:
<!NOTATION epsi SYSTEM "">
is exported as:
<!NOTATION epsi PUBLIC "">
Again, avoid the issue by declaring the notation in your EDD.
>2. When exporting to XML, the reference to DTD is stored with full path
>info: <!DOCTYPE Section SYSTEM "file:
>///E:/vijay/KOM107C-XML/FMApp/komori.dtd" - how can I make FM store only
>the DTD name, without full path? The XML files need to be processed on
>different systems that don't have access to the same server.
Good news, bad news on this one. There is a r/w rule that I believe should
do what you want:
writer {external dtd is "komori.dtd";}
Unfortunately, FM assumes that the specified file exists in the same folder
as the FM file being saved. Thus, the rule works if you save the XML file
to that folder. Suppose, however, that you have a main project folder with
two subfolders, one called fm and once called xml. If your FM file is in
the fm subfolder, and you save it as ..\xml\output.xml. FM uses
..\xml\komori.dtd as the external identifier. Since there's no need to
store the DTD there, such a file is not likely to exist. Short of using a
custom FDK client, the workaround is to keep both FM and XML versions in
the same folder.
--Lynne
Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application development,
and training
lprice at txstruct.com http://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284
More information about the framers
mailing list