Skip to main content
C
cleccese1-Visitor
1-Visitor
December 17, 2013
Question

Proper Way to Switch to a New DTD?

  • December 17, 2013
  • 9 replies
  • 2043 views

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?

    9 replies

    L
    LynnHales1-Visitor
    1-Visitor
    December 17, 2013
    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.


    C
    cleccese1-VisitorAuthor
    1-Visitor
    December 17, 2013

    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.

    A
    AndyEsslinger1-Visitor
    1-Visitor
    December 17, 2013
    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]
    E
    ebenton1-Visitor
    1-Visitor
    December 17, 2013
    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.
    L
    LynnHales1-Visitor
    1-Visitor
    December 17, 2013
    Hey give me a call tomorrow around 9 or so if you can or we can work out a
    time that is convenient.



    Lynn


    C
    cleccese1-VisitorAuthor
    1-Visitor
    December 17, 2013

    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.

    C
    cleccese1-VisitorAuthor
    1-Visitor
    December 17, 2013

    Thanks everyone!

    L
    LynnHales1-Visitor
    1-Visitor
    December 18, 2013
    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:

    C
    cleccese1-VisitorAuthor
    1-Visitor
    December 18, 2013

    Thanks again, Lynn! You are a great resource!

    Terms & ConditionsAccessibility statement