[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Anomalies/Bugs in FM+SGML V5.5.6 & V6.0

A TALE OF TWO CALS TABLES

Has anyone else noted the two anomalies described below, which occur in 
both V5.5.6 and V6.0 of FM+SGML?

ANOMALY 1: An error is logged when "nmtoken" is used in any attribute 
read/write rule. For example:
         nmtoken attribute "tgroupstyle" is fm property table format;
         number attribute "colsep" is fm property column ruling;
In the case above, an error is produced for the first rule above when 
checking the read/write rules for an application definition in which the 
referenced DTD declares the tgroupstyle attribute to be of type NMTOKEN.

In chapter 21 of the Developer's guide the attribute rule is declared to 
have the form:

         [sgmldv] attribute "attr" {...
                 subrule;
...}
Where sgmldv (SGML attribute type) is allowed to have the legal values: 
cdata, name, names, nmtoken, nmtokens, number, numbers, nutoken, nutokens, 
entity, entities, notations, id, idref, idrefs, and group.

For some reason, however, any attempt to use nmtoken anywhere in the 
read/write rules (not just tables) is logged as an error when checking the 
read/write rules, even though the DTD declares the affected attributes to 
be of type NMTOKEN.

ANOMALY 2 relates to the translation, on export to SGML, of (what I 
consider to be) two different CALS-compliant tables.

I have a DTD which declares two types of CALS-compliant tables, as follows:
===============================================
<!-- TABLE TYPE 1 -- >

<!ELEMENT Table      - -  (Title?, tgroup)>
<!ATTLIST Table      frame     (top|bottom|topbot|all|sides|none)  #IMPLIED
                      colsep    NUMBER    #IMPLIED
                      rowsep    NUMBER    #IMPLIED
                      orient    (port|land)  port
                      pgwide    NUMBER    #IMPLIED >

<!ELEMENT tgroup     - O  (colspec*, spanspec*, thead?, tfoot?, tabody) >
<!ATTLIST tgroup     cols      NUMBER    #REQUIRED
                      tgroupstyle  NMTOKEN   #IMPLIED
                      colsep    NUMBER    #IMPLIED
                      rowsep    NUMBER    #IMPLIED
                      align     (left|right|center|justify|char)  left
                      charoff   NUTOKEN   50
                      char      CDATA     #IMPLIED >

<!ELEMENT tbody      - O  (row+) >

<!ELEMENT row        - O  (entry+) >
<!ATTLIST row        rowsep    NUMBER    #IMPLIED >

<!ELEMENT entry      - O  ((Para | Unlist | Numlist | Note | Graphic |
                               (Warning*, Caution*))+) >
<!ATTLIST entry      namest    NMTOKEN   #IMPLIED
                      nameend   NMTOKEN   #IMPLIED
                      spanname  NMTOKEN   #IMPLIED
                      colname   NMTOKEN   #IMPLIED
                      colsep    NUMBER    #IMPLIED
                      rowsep    NUMBER    #IMPLIED
                      morerows  NUMBER    #IMPLIED
                      rotate    NUMBER    #IMPLIED
                      valign    (top|bottom|middle)  top
                      align     (left|right|center|justify|char)  left
                      charoff   NUTOKEN   #IMPLIED
                      char      CDATA     #IMPLIED >

<!ELEMENT thead      - O  (row+) >
<!ATTLIST thead      valign    (top|middle|bottom)  bottom >

<!ELEMENT tfoot      - O  (row+) >
<!ATTLIST tfoot      valign    (top|middle|bottom)  bottom >

<!ELEMENT colspec - O EMPTY>
<!ATTLIST colspec
    align    (left|center|right|justify|char) #IMPLIED
    char     CDATA     #IMPLIED
    charoff  NUTOKEN   #IMPLIED
    colname  NMTOKEN   #IMPLIED
    colnum   NUMBER    #IMPLIED
    colsep   NUMBER    #IMPLIED
    colwidth CDATA     #IMPLIED
    rowsep   NUMBER    #IMPLIED
 >

<!ELEMENT spanspec - O EMPTY>
<!ATTLIST spanspec
    align    (left|center|right|justify|char) #IMPLIED
    char     CDATA     #IMPLIED
    charoff  NUTOKEN   #IMPLIED
    colsep   NUMBER    #IMPLIED
    nameend  NMTOKEN   #REQUIRED
    namest   NMTOKEN   #REQUIRED
    rowsep   NUMBER    #IMPLIED
    spanname NMTOKEN   #REQUIRED
 >
<!-- TABLE TYPE 2. Note that this table type shares elements Row, Entry, 
Thead, Tfoot, Colspec, and Spanspec with TABLE TYPE 1 -->

<!ELEMENT Tabdat     - -  (Effect?, Title?, Tabgroup)>
<!ATTLIST Tabdat     frame     (top|bottom|topbot|all|sides|none)  #IMPLIED
                      colsep    NUMBER    #IMPLIED
                      rowsep    NUMBER    #IMPLIED
                      orient    (port|land)  port
                      pgwide    NUMBER    #IMPLIED >

<!ELEMENT Tabgroup   - O  (colspec*, spanspec*, thead?, tfoot?, tabody) >
<!ATTLIST Tabgroup   cols      NUMBER    #REQUIRED
                      tgroupstyle  NMTOKEN   #IMPLIED
                      colsep    NUMBER    #IMPLIED
                      rowsep    NUMBER    #IMPLIED
                      align     (left|right|center|justify|char)  left
                      charoff   NUTOKEN   50
                      char      CDATA     #IMPLIED >

<!ELEMENT tabody     - O  (row+) >
===================================================================
Elements Tgroup and Tabgroup are specified in the EDD as being the two 
Table elements. Attributes which equate to fm properties (e.g., 
Tgroupstyle) in the CALS table model elements are not included in the EDD, 
nor are the colspec and spanspec elements included in the EDD. The only 
relevant deviation between the two table types is the use, in TABLE TYPE 2, 
of elements Tabgroup and Tabody, which replace elements Tgroup and Tbody 
used in TABLE TYPE 1.

In the EDD, the content models for elements Table, Tabdat, Tgroup, and 
Tabgroup are as follows:
Element Table
General Rule: Title?, Tgroup

Element (Table) Tgroup
General Rule: Thead?, Tbody, Tfoot?

Element Tabdat
General Rule: Effect?, Title?, Tabgroup

Element (Table) Tabgroup
General Rule: Thead?, Tabody, Tfoot?


The read/write rules for both table types are (except for the element name 
differences described above) identical, and conform exactly to those set 
forth in Appendix C of the Developer's Guide.

I created an FM+SGML test file into which the EDD element definitions had 
been imported. In this file, I created two identical tables, one using 
Table Type 1, the other using Table Type 2. Each table had 5 columns, a 
heading row, two body rows and a footing row. One of the body rows, and the 
footing rows, had horizontal straddles across two columns. Also, one of the 
columns had a vertical straddle across both body rows. I exported the test 
file to SGML and then imported the SGML instance back into FM+SGML. The 
Table Type 1 table survived the round-trip completely intact. In the Table 
Type 2 table, the vertical straddle survived, but the two horizontal 
straddles did not, and the text in the columns of the same row that were to 
the right of the straddles was shifted one column to the left, leaving the 
fifth column empty. For both table types, the exported value in the 
Tgroupstyle attribute matched the name of the FM table tags used to create 
the two tables, and, on import to TM+SGML, the values of Tgroupstyle 
produced tables using the same table tags that were originally used to 
create the two tables in the test file.

Upon examining the resulting SGML instance produced from the test file, I 
found that colspecs were correctly produced for each column in Table Type 
1, but none were produced for Table Type 2. Also, FM+SGML had properly 
reversed the positions of the Tbody and Tfoot elements in Table Type 1, but 
that reversal was not performed for Table Type 2, despite the fact that the 
Tabgroup content model in the DTD specified that the order should be 
Tfoot?, Tabody.

I also experimented with removing element Title from the content models for 
Table and Tabdat and moving it (in both the DTD and the EDD) to the first 
position in the content models for elements Tgroup and Tabgroup 
respectively. The EDD and read/write rules were also modified to specify 
that the Title element was now a Table Title Element. The test file was 
modified to put the table titles inside the two tables (everything else 
about two table structures and content were unchanged), and the test file 
was again exported to SGML. In this test, FM+SGML discarded the Title 
element in Table Type 1, but properly preserved the Title element in Table 
Type 2, Otherwise, Table Type 1 round-tripped intact, and the same 
anomalies described previously occurred again in Table Type 2.

My conclusion is that, although the content models and attributes for the 
Table Type 2 elements fully conform to the CALS table model, the two 
element name discrepancies (Tabgroup instead of Tgroup, Tabody rather than 
Tbody) causes FM+SGML to assume that, on export, Table Type 2 was not 
compliant with the CALS table model, hence no colspecs, and no switching of 
the positions of Tabody and Tfoot were produced, even though, in both 
tables, all of the attributes corresponding to table properties in the 
Entry element were properly produced on export.

Nothing in the Developer's Guide suggests that the element names for CALS 
tables must exactly match the element names given in Appendix B of the 
Developer's Guide, nor does the Developer's Guide state anywhere that a 
table title element included in the Tgroup content model of an otherwise 
fully CALS-compliant table will be arbitrarily thrown away on export, 
without even producing an error log message which reports that action.


====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
177 Riverside Ave., STE F, #1151, Newport Beach, CA 92663
---Subscribe to the "Free Framers" list by sending a message to
majordomo@omsys.com with "subscribe framers" (no quotes) in the body.



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **