CALS DTD and its use

[ptc-953343]

This isn't a direct Arbortext question but I know that a number of the
folks here have experience with this DTD or its derivatives.

So CALS is an SGML DTD do you find yourself ever wanting to use some of
the new functionality that XML brings? Maybe you haven't seen some of the
advantages, for myself I'm coming back into the milspec work after having
dealt with DITA and schemas for the last few years.

I'm wondering if anyone has attempted to convert one of these DTDs (like
the NAVSEA2) to an XML schema? I know this would be very complicated
trying to keep this as an XML DTD becasue of all the inclusions and such,
but with a Schema you could achieve this with local element models.

I would love to redesign these DTDs and bring them up to todays design
standards, but it would just be handy to have them as is in XML.

Has anyone attempted this or is there any interest in trying this?

..dan

[ebenton]

We use a custom SGML DTD which was derived from CALS (38784), but it is one of our output DTD's. Nobody authors in it. We author in a custom XML DTD and transform to the CALS-like DTD for PDF output and to other DTDs for other outputs. So we would not have much interest in converting CALS to XML.

[jgroves]

The NAVSEAC2 DTD was converted to an XML DTD in 2005 and is available in
the CALS NAVY Repository. There is a great schema there also that is
called the NSP schema. It is a very good schema.

John

[ptc-953343]

Well you do, you have just already done it. Did you write an XML DTD or schema? How much trouble did you have with the inclusions/exclusions? I have one project where there was an IETM delivery only and they did a quick pruning of the SGML DTD, converted it to an XML DTD and added a few things. With a quick look I don't think they really worried about trying to get back to the NAVSEA2 DTD. I've got a new project where the Navy wants a PDF manual and they want the final product conformant to NAVSEA2. I really don't want to deal with it as SGML but I can't convince them to manage it internally as XML. This is also impacting a choice on the CMS as I would like an XML native system, but that doesn't work nicely if I only have SGML content. That is I can't take advantage of the XML features, same goes with managing the content even in the Editor. ..dan --------------------------------------------------------------------------- Danny Vint Specializing in Panoramic Images of California and the West

[ptc-953343]

Well I was told by my Navy counter part/customer that they weren't sure at how well it was rationalized when the conversion was made. Has anyone used this to develop to XML but deliver offically to the SGML version? What I'm worried about is being tripped up by an exclusion that would invalidate my XML. I'll go take a closer look at this in more detail. I knew it was out there but had been warned off on using it. ..dan --------------------------------------------------------------------------- Danny Vint Specializing in Panoramic Images of California and the West

[LynnHales]

Dan,

There has really never been a single "CALS" DTD. 38784 pretty much started things in the early 90's and it still remains an SGML DTD.

28001 tried to be the 'all encompassing' DTD, but failed miserably.

NAVSEAC2 is one of the worst DTD's in the DOD world that I've seen. It does not enforce specification requirements and pretty much allows the author to do dumb things (like put a couple of 'forewords' in the manual BEFORE the cover page). I haven't really looked at the NAVSEAC2 XML DTD or schema, but if they are done like the SGML DTD, I shudder.

The Army switched their 40051 DTD from SGML to XML in 2000. The biggest problem, as you said, was how to deal with the SGML 'exceptions'. When we did it, for inclusions, we went to the lowest element level and placed them there. Some people were not happy when tables and figures were no longer allowed just anywhere, but they've gotten used to it.

Exclusions were a bit more difficult to write and often resulted in new elements (like a <para> and a <trim.para>, the <trim.para> containing fewer elements than the regular <para> to preclude allowing what was once and exclusion).

S1000D has basically stopped using DTD and migrated to schema. When they did their SGML to XML, they did inclusions (mainly tables, figures and foldouts) as an entity they tacked on nearly everywhere. So now if you have a requirement for a single paragraph of text, it may be repeatable because the group allows multiple tables, figures, or foldouts.

I did most of the 40051 conversion so if you have some other questions, drop me a note off line.

Lynn


---- Dan Vint <dvint@dvint.com> wrote:
> Well I was told by my Navy counter part/customer that they weren't sure at
> how well it was rationalized when the conversion was made. Has anyone used
> this to develop to XML but deliver offically to the SGML version? What I'm
> worried about is being tripped up by an exclusion that would invalidate my
> XML.
>
> I'll go take a closer look at this in more detail. I knew it was out there
> but had been warned off on using it.
>
> ..dan
>

[LynnHales]

Dan,

There has really never been a single "CALS" DTD. 38784 pretty much started things in the early 90's and it still remains an SGML DTD.

28001 tried to be the 'all encompassing' DTD, but failed miserably.

NAVSEAC2 is one of the worst DTD's in the DOD world that I've seen. It does not enforce specification requirements and pretty much allows the author to do dumb things (like put a couple of 'forewords' in the manual BEFORE the cover page). I haven't really looked at the NAVSEAC2 XML DTD or schema, but if they are done like the SGML DTD, I shudder.

The Army switched their 40051 DTD from SGML to XML in 2000. The biggest problem, as you said, was how to deal with the SGML 'exceptions'. When we did it, for inclusions, we went to the lowest element level and placed them there. Some people were not happy when tables and figures were no longer allowed just anywhere, but they've gotten used to it.

Exclusions were a bit more difficult to write and often resulted in new elements (like a <para> and a <trim.para>, the <trim.para> containing fewer elements than the regular <para> to preclude allowing what was once and exclusion).

S1000D has basically stopped using DTD and migrated to schema. When they did their SGML to XML, they did inclusions (mainly tables, figures and foldouts) as an entity they tacked on nearly everywhere. So now if you have a requirement for a single paragraph of text, it may be repeatable because the group allows multiple tables, figures, or foldouts.

I did most of the 40051 conversion so if you have some other questions, drop me a note off line.

Lynn


---- Dan Vint <dvint@dvint.com> wrote:
> Well I was told by my Navy counter part/customer that they weren't sure at
> how well it was rationalized when the conversion was made. Has anyone used
> this to develop to XML but deliver offically to the SGML version? What I'm
> worried about is being tripped up by an exclusion that would invalidate my
> XML.
>
> I'll go take a closer look at this in more detail. I knew it was out there
> but had been warned off on using it.
>
> ..dan
>

[ptc-953343]

I went form that early 28001 days to 15 yrs later having to deal with the NAVSEAC2 DTD. I've not seen the other branches modifications to the original DTD but figured it existed. This information will be useful, plus the specific comments about NAVSEAC2. I've not been asked to do a real project but you know how it is you propose something they want a number and then they will hold you to it. With XML schemas, I think you could get closer to the original intent of the exclusions/inclusions and get a pretty accurate/comaptible model between the designs. With XML DTDs you have to make the decision on how/where to break the old design. thanks for the info. ..dan --------------------------------------------------------------------------- Danny Vint Specializing in Panoramic Images of California and the West

[ebenton]

We wrote an XML DTD for our authoring DTD. We think that it has a rich enough tag set to allow transforming to any output. When we wrote the authoring XML DTD we already had the output SGML DTD, which we had deliberately designed without exclusions or inclusions.
Our Navy customer does not care how we manage the source data, as long as they get their SGML output for IETMs (87269-like) and PDF. One of the tools that we use for transforming XML to SGML is DSSSL (JADE). We used to say that we had two of the ten people in the world who knew DSSSL well. Now we only have one of them. The other person is still available to us, theoretically.