Absolute path in Doctype DTD makes DTD unavailable on other machines

[shoose]

Hi all,

When saving to XML, I understand that Frame takes the relative path to the DTD as described in structapps.fm (in our case, $STRUCTDIR\xml\xdocbook\app\docbookx.dtd) and generates an absolute path in the XML it writes, like this:

DOCTYPE chapter SYSTEM "file:///C:/Program%20Files/Adobe/FrameMaker9/structure/xml/xdocbook/app/docbookx.dtd"...

This, of course, makes the files impossible to open on a machine that has Frame installed in something other than "Program Files".  Any way to get around this?  Have Frame generate a relative path in some way?  I've researched this in the ref and dev guides and don't see any way to control this.  I did try adding something to the rules, like this...

writer external dtd is system "docbookx.dtd";

but then Frame just looks directly in the folder that contains the document you're trying to open.

Thanks for any suggestions.

- Shelley

[Michael_Müller-Hillebrand]

Shelley,

A DTD is an external entity and therefore you can use a feature of the Structure Application definition to solve this problem. Add the Entity Search Path in the structapp file and make sure it points to the local path. FrameMaker will then look in this folder(s) as well if it can not find an entity.

I am not sure if this works with full paths, because I always use it only with <!DOCTYPE chapter SYSTEM "my.dtd" >.

- Michael

[Russ Ward]

Hi Shelley,

From your post, I'm wondering if you really meant to say that the following represents a relative path:

$STRUCTDIR\xml\xdocbook\app\docbookx.dtd

This is an absolute path. $STRUCTDIR is just a shortcut for saying "the path to my structure application in my installation directory." That's why that "Program Files" absolute path is written to your XML.

You did observe that sticking the filename alone results in a relative path. You can expand that for other relative path conventions, such as putting:

somefolder/mydtd.dtd

...in which case the DTD will be expected in a subfolder named "somefolder". In any case, if you want to open it in an app that considers the DTD, it will have to be somewhere that it can be found. In my practice, I do exactly what you tried with the relative path experiment and simply include the DTD (actually schema in my case) with the XML files if they ever need to travel.

Russ

[Guest]

Hello Shelly,

as Michael has already written: It's enough to set just <!DOCTYPE chapter SYSTEM "myfile"...>

If you are refering to the second line that is saved in the xml:

You can modify that path in the read and write rules.

writer external dtd is SYSTEM "myfile";

Regards,

Anna

[shoose]

Hi all,

Thanks for your help and replies.  I tried your suggestions but am not doing it right apparently.  We have two machines: A and B.  A has Frame installed in the default lcoation "Program Files\Adobe\...", while B has it in "Programs\Adobe\..."

Machine B cannot find the DTD, with this setup:

The rules say this:

writer external dtd is system "docbookx.dtd";

The structapps.fm says this within the Entities tag:

Entity search paths
C:\Programs\Adobe\FrameMaker9\Structure\xml\xdocbook\app\

I have also tried changing this in structapps.fm:

DTD:    $STRUCTDIR\xml\xdocbook\app\docbookx.dtd

to just this:

DTD:    docbookx.dtd

Still this does not work, with this error:

Error at file C:\Users\techdocs\AppData\Local\Temp\FMTDE7A.tmp, line 11, char 3, Message: Could not open DTD file: C:\Users\techdocs\AppData\Local\Temp\docbookx.dtd
Parse error at line 11, char 1: Error in processing external entity reference
Parsing aborted.
Error at file C:\framefiles\document.xml.597, line 27, char 3, Message: Could not open DTD file: C:\framefiles\docbookx.dtd
Parse error at line 27, char 1: Error in processing external entity reference
Parsing aborted.

So it is clearly not using the entity search path, as it's looking directly in the folder where the XML instance document resides.  Can anyone tell what is wrong here?

Thanks again,

Shelley

[ScottPrentice]

Hi Shelley...

One possibility is that you're not actually using the structure app that you think you are. Have you created a custom structure app using the default docbook app as the base? If you haven't changed the "Structured Application" name in the EDD to point to your new app name, it'll actually use the old app definition when saving the file. It'll open with the app you specify, but it will save with the app specified by the application name node in the EDD.

Try this .. after opening your file in FM, choose .. Structure Tools > Export Element Catalog as EDD. In the resulting EDD, check the value for the "Structured Application" node .. is it the app name that you'd expect?

This may not be the problem, but I've seen it happen many times and can cause much grief.

Cheers,

...scott

Scott Prentice

Leximation Inc.

www.leximation.com

[Guest]

Hi Shelly,

I had a look again not only in my read and write rules, but also the stracctapps.fm, and made some test.

In my rw-rules:

writer external dtd is public "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd";

In the stracctapps.fm NOT the DTD, but:

Public ID: -//OASIS//DTD DITA Composite//EN

Filename: STRUCTDIR\xml\dita\app\dtd\ditabase.dtd

=>

For your rw-rules

writer external dtd is system "docbookx.dtd";

you probably need a) an "ID" and b) something like

System ID: ###