tgroup in mixed content

[lhales]

Greetings folks,

I have an interesting problem that I would like one or two of you to test
for me. My boss and I were doing some work in 5.2 after making a change
to our XML DTD. We had to add a to our content model.
Don't ask why, we HAD TO. 🙂

First couple of times my boss tried to enter a new after we made
the change he'd get the 'insert table' box asking the name of the wrapper
and to enter the number of columns and rows. If he cancelled the dialog,
the would not be entered. Then suddenly it started working right.
I tried it and got the same results. I tried it in 5.2 and had problems,
closed 5.2 opened 5.1M using the same DTD and instance, the went in
as advertised. Closed 5.1 reopened 5.2 and it started working. Now I
can't make it fail.

So if I could find a kind soul (I'll even take that devil Ed's help 😄
[he's always saying "Tables are the spawn of Satan"]) or two who has 5.2
and could make a change to a test DTD they might have and let me know the
results, I would greatly appreciate it. I am using Windoze XP SP2 with
Epic 5.2. What would really be nice if for someone to try it in and
earlier version before they try the 5.2 and see what happens.

I've got my bug report almost done. Just want to make sure it isn't a
'CSC' thing.

Many thanks.

Lynn

[ebenton]

What's the exact new content model? Is it (tgroup, #PCDATA) or
(tgroup*, #PCDATA) or (tgroup?, #PCDATA) or what? Yes, tables *are* the
spawn of Satan!

[lynn]

Ed,
It is an XML mixed content model.
(#PCDATA | tgroup | xref | other_el_toro_poopoo)*
Lynn

[ebenton]

Lynn,
Using Arbortext 5.2, I tried changing the DTD for our CALS-like doctype
from:


to:


And when I attempted to insert a new <para>, I was also prompted for the
rows and columns of a table with a para wrapper tag.

I changed the content model to tgroup* | %text; | %format;)+)

And I was still prompted for the same thing when I tried to insert a new
para.

As you can see from the tag minimization markup, this is an SGML
doctype. I didn't try it with XML.

Hope this helps you somehow.

[ebenton]

I even tried changing the content model to : ((#PCDATA | %text; | %format;)+, tgroup*) and Epic *still* prompted me
about the rows and columns.

I even made an invalid document, so that you could insert any element
anywhere, and Epic still prompted me about rows and columns when I
inserted a para.

[brent.hartwig]

Without validating why Epic is doing what it is doing, I'm curious why
one would not have a table-specific wrapper element to tgroup (table,
informal-table, table-wrapper, grid, etc.).

I wonder if the insertion of tgroup's parent triggers Epic's row/col
prompt. Last I knew, Epic doesn't include AI...so why it changes
behavior is also interesting. Anything "odd" showing up in the
preference file?

-Brent

[lhales]

Brent,

I told you not to ask. We were forced into this because our table model
REQUIRES both a table number and title. We have been unable to get relief
from this requirement in the standard. 😞 So in order to allow for those
small, innocuous, but fairly common small tables that are untitled and
unnumbered (take a look sometime at how many table like things are in our
data) we had to do something.

What I think is happening, is that the <tgroup> model has the real table
meat. The <colspec>'s (if used), the 'cols' attribute (#REQUIRED) and the
<tbody> element with its required <row>.

<rambling thought="yes" importance="little_or_none">HMMM now that is an
idea. I wonder what would happen if I defined something like a parts list
as a <parts_list> then in the <tgroup> specified the number of columns
(still doesn't answer the <row> entry though). Nice idea Lynn, but you
still wind up losing the IDENTITY of your data by doing a generic table.
What is the information type for row 4 column C? </rambling>

<soapbox>I tend to agree with Ed that tables are the "spawn of Satan".
Though having data organized in neat rows and columns can aide in viewing,
there are other methods to present the information. My major problem with
a table is that once you put your data in a table cell, it is that a table
cell. The identify of the information is forever lost. In some cases
this may be acceptable, in others, not even close. The parts list is an
excellent example. Consider the part number, the (for most government
manuals) CAGE {contractor and government entity) code, or different usable
on, effectivity or applicability codes. Much easier to search on an
element of that type than a cell in a column. With the generic table
model, these columns can change, but the element name probably would not
(though most DOD DTD/schemas use <partno> for the part number element and
S1000D uses <pnr>).

Tables should be used in a very limited manner. Like I said, there is an
occasional need, but they are not for everything.</soapbox>

Lynn

[lhales]

Ed,

Despite calling you a devil, I do appreciate the check and yes that does
help considerably. Now it has failed in both the SGML and XML world. In
any case, I have filed a case with Arbortext on this. We shall see.

Lynn

[ebenton]

We can get around some of the "this stuff sure looks good in a table"
attitude by using two different DTDs. An authoring DTD requires the
authors to put the data into "semantic" markup: (i.e. <partnum>,
<nomenclature>, <modelnum>, <quantity>, etc.) Then we transform it to
our publishing doctype/DTD, which renders it in the form of a table.
You can even generate a table in the screen FOSI for the authoring DTD,
if you want to give authors a warm, fuzzy feeling. The sticky part about
doing this is that you have to do some designing up front with the
authors to say that <partnum> will be in column one, <nomenclature> in
column 2, <quantity> will be in parenthesis in the same column following
<nomenclature>, etc. etc.
The only thing that traditional table markup allows the data to say
about itself is, "I am '1234-567-ABC' and I am in column two of row
three."

This approach works well for data that can either already be found in a
database or that will someday be in a database. When a database
interface with our XML documents is available, and we do hope to have
one some day, it is much easier to extract the contents of the
<nomenclature> tag and put it into the correct database field than it is
to search through random tables looking for strings that might match
what you want, or hoping that everything you want is in column one of
all tables that have the word "parts" in the title.
For existing "legacy" tables, it is frequently difficult to do anything
more than continue to allow table markup.

[lhales]

Ed,

You said a bad word. Legacy.

We have been forced to make changes (or keep existing markup) solely to
support the "that's the way we've always done it" syndrome. I am guilty
of that sometimes, but I try to see why we can't change. Just because I
can't convert my legacy data without reorganizing is not reason not to
change. Just because someone put it in the data does not mean it belonged
there. Did the old requirements document specify it? If yes, is it still
needed or can it be removed with no impact on the usability of the data?

We had a case where a TM developed to the now decade rescinded 63038 spec
(Army, using chapters, sections, etc [a 38784 like structure]) was to be
converted to work package format according to 40051. The TM was sent to a
conversion house with instructions that the TM was to be returned looking
just like it had before the conversion (the appearance and organization
between the two specs is nowhere near similar). The government folks even
sent markup mapping that DID not follow the DTD or the standard. Needless
to say the poor (relatively speaking) conversion house was at a loss.

Having dealt with several conversion programs, here's my two cents (with
inflation)

1. If the data is adequate as is and is not being routinely changed,
don't convert it (at least not right now, maybe later)
2. If you do convert, identify what needs to be converted and provide
adequate mapping to who ever is doing the conversion.
3. If the conversion makes major changes in formatting or organization,
make the conversion a REVISION and not a change.
4. If the conversion is being done externally, provide subject matter
points of contact who can answer simple technical questions. Develop a
quick turn reporting of errors process. Most conversions I have been
involved with have found numerous errors that need to be corrected NOW.
Conversion houses don't have the technical expertise to say a task is
wrong, but they can find problems with references, or stuff that was put
in because it could be done and is not and never was in the requirements
and other such things that are wrong and the correct information needs to
be provided.
5. If you are the data owner/manager, be active in the conversion process
(proactive, reactive and any other active you need to be).

Lynn

[ebenton]

Yes, we could go on and on and on and on about "legacy" manuals needing
to look *exactly* like they used when they were written with chisels on
stone tablets. This problem seems to be particularly tenacious when
dealing with military technical manuals. Between old soldiers and old
civil servants, I don't know which is more frightened of a change in
appearance of the manuals. Today's soldiers, sailors and airmen who
grew up playing video games don't seem to be bothered.

[lhales]

Ed,

Exactly, that is why it is nice to be an 'old' retired military type
working in this field. I'm not the young computer geek. To me java is
still a cup of coffee (or an old song by Al Hirt).

We still have people out there who want to MANUALLY count each figure and
table as well as MANUALLY build their TOC and INDEX.

I wonder if I can still get a good deal on that old quarry. Might still
be a few job guides left in it. 😄

Lynn

[AndyEsslinger]

Lynn,

This message rings a bell. XML possibilities unknown, but we use a
tabmat element for tabular material without title or title in our SGML
for MIL-STD-38784:




Then the tabmat is included in our text parameter entity (which makes it
legal in para elelments and elsewhere):


emphasis | applicabil | graphic | extref | dataiden | hcp | hci | esds |

nsp | oci | ocp | fcp | acronym | prindex | secindex | nameloc | clink |

ilink | object)+" >

Tabmat has the same attributes from the cals table and Epic seems to
process them correctly. I discourage their use but there are times when
the authors insist on sticking in an unnumbered table.

Maybe you just need a wrapper elelment to make it work?

I also found a similar element in another DTD that I think is from
Arbortext texk support for something I hit several years ago (the
%tbl.table-main.mdl; boils down to tgroup+):


frame (top | bottom | topbot | all | sides |none) #IMPLIED
colsep %yesorno;
'1'
rowsep %yesorno;
'0'
%tbl.table.att;
%bodyatt;


-Andy



\ / Andy Esslinger Lockheed Martin Aeronautics Co.
_____-/\-_____ (817) 777 3047 LM Aero Ft. Worth F/A-22 TOD
\_\/_/ Box 748, Mail Zone 4285, Ft. Worth, TX 76101

[AndyEsslinger]

"... without title or title" should have been ".. without number or
title"

-Andy

\ / Andy Esslinger Lockheed Martin Aeronautics Co.
_____-/\-_____ (817) 777 3047 LM Aero Ft. Worth F/A-22 TOD
\_\/_/ Box 748, Mail Zone 4285, Ft. Worth, TX 76101

[lhales]

Andy,

That is an idea I hadn't thought of. We at one time had a <tabmat> element, but it was a real tabbed table and not a demented version of the CALS model. We droppped it because we were having problems making it really work.

I'll give it a try. All Epic seems to be looking for is a wrapper tag.

Lynn

-----"Esslinger, Andy W" <-> wrote: -----

To: adepters@arbortext.com