Proper Way to Switch to a New DTD?

[cleccese]

How should one switch to a different DTD?

I'm using 5.4 m170 with SGML locally. I was given a new DTD with a different name. I compiled the new DTD and it failed with a syntax error, so I recompiled the old DTD successfully, saved the SGML file but it's still using the new DTD. Recompiled again, saved, shut down Arbortext, opened it again and SGML is still using the new DTD. The catalog is pointing to the old DTD.

The new DTD was uploaded to the PE Server without changing the catalog path. I asked someone in production to recompile the new DTD sincer her SGML file couldn't f ind the old DTD, and the compile succeeded. But every time she opens the SGML file it says it can't find the DTD, and then it can't find the stylesheet, either. I assumed it was because the catalog path had to be renamed to the new DTD but I thought saving the SGML file after recompiling the new DTD would have overridden that. Anyway, they renamed the new DTD on the server to match the old DTD.

I still would like to know why my SGML file is not switching to the most recently compiled DTD? And also why the new DTD fails locally but compiled from the server?

[LynnHales]

Caroline,



There could be a couple of reasons for this. The CATALOG is the most likely
cause. If you are still using SGML, the CATALOG will go to the first DTD in
the CATALOG it encounters that matches the PUBLIC IDENTIFIER contained in
the SGML file (this is a 'been there swore at that one').

What one should do when they revise an SGML DTD is change the PUBLIC
identifier and keep the DTD name the same. The ONLY time you should change
DTD names is if you have made changes where the old and new versions are no
longer fully compatible. Even then, placing the DTDs in different folders
will fix that.



All that compiling the SGML DTD (not needed for an XML DTD or schema) does
is build a file with the DTD structure in it that Epic will work from. Epic
in SGML DOES NOT directly read the DTD. L



When you use the new DTD are there any 'context' errors or new 'completeness
errors' showing up in the files that were previously OK?



Lynn



You have my number if you want to call.

[cleccese]

Hi Lynn,

I was getting a syntax error when compiling it locally, so it did not compile. When it was being compiled on the server it threw these new errors:

*** Error on line 166 in file \\dtbtcnas...:
[A11054] Invalid value "other" for required attribute "type"

*** Error on line 242 in file \\dtbtcnas...
[A11080] Undefined entity reference: ldquo

*** Error on line 242 in file \\dtbtcnas...
[A11080] Undefined entity reference: rdquo

OK so the gist I'm getting is that the catalog path to the DTD and the SGML public identifier must match, which right now it doesn't on the server.

[AndyEsslinger]

Does your SGML document have the correct DTD identified in the header?



Also, suggest that you can force a recompile by deleting the *.ptd (the compiled DTD file) from your local doctype directory. I have been misled by Arbortext not compiling a doctype unless Arbortext thinks it needs to be re-compiled.

Sorry if this was already suggested. I only read the e-mail at the bottom of the thread.

-Andy


Andy Esslinger LM Aero - Tech Order Data
(817) 279-0442 1 Lockheed Blvd, MZ 4285
(817) 777 3047 Fort Worth, TX 76108-3916
[Title: Integrated Fighter Group]

[ebenton]

The first error could be the type of data required for that attribute by your DTD. In order to have the value "other", the DTD probably needs to say CDATA.

The other two might be from using curved double quotes. Replace the right double quote and the left double quote with straight double quotes from your keyboard.

Hope this helps.

[LynnHales]

Hey give me a call tomorrow around 9 or so if you can or we can work out a
time that is convenient.



Lynn

[cleccese]

Hi Lynn,

I think we're OK. Just for the record, we switched from 38807C-AV6aD2P0.dtd to 38807D-AV9D0P0.dtd

I was able to get it to compile locally after deleting a lot of duplicate entries in the new DTD.

For the one error I was still getting, the DTD att declaration was originally this:

And in the new DTD it's this:

So we will use a different att value instead of "other", which we should anyway.

[cleccese]

Thanks everyone!

[LynnHales]

Caroline,



The change to the distribution statement is really valid and correct over
what was there previously. DODI 5230.24 lists the allowable distribution
statements and their text. So the change from 'A' (unlimited distribution)
and 'other' to those allowed by the DOD is really long overdue. So please
use the updated <distrib> element attributes.



What would be interesting with the way the Air Force is doing this would be
how they are presenting the statements. With the exception of Distribution
Statement A, you need to have a date and release organization (as a
minimum), and for statements B through E you need a reason for not releasing
the information. All this is in the DODI.



You can download a copy of the DOD Instruction from this site:

[cleccese]

Thanks again, Lynn! You are a great resource!