🚀 go-pugleaf

Hi,

Your DTD must have an attribute for number of columns in the table element. Since you are not using CALS or OASIS table model, you need to build your own rw-rules for it.

Let's call this attribute "cols" and also assume that you use lowercase element names in the DTD. So your r/w rules should look like:

element "table" {
is fm table element "Table";
attribute "cols" is fm property columns;
}

If there is no reason not to use standard table model, you should use one. The benefit is that then yuou could use the available r/w and edd definitions.

BR, Martti

If I stick with the CALS model, do I need to still define the number of columns. My whole point is that I may want to implement an "n" column table, where "n" can be any number from 1-15. Are you saying that adobe is going to make me manually enter 15 or however many table types, each one with a different number of columns for its attribute. I don't see how this problem could have never popped up before and how f/m could not have a better way of doing this than by brute force.

Hank

Hi Hank,

You don't need to enter it manually. Frame just needs the number of columns while reading in XML (it either comes from XML or it could come from r/w rules when dealing with fixed-number-of-cols tables).

The r/w rules will do the work for you, internally frame knows the number of columns while writing XML and r/w provides the mapping to XML for that value. During read, frame must know the number of columns while building the table from XML. Without it, everything collapses as you've seen.

So, when things are properly defined, there is no manual intervention needed.

Martti

Hi Marti,
What I mean is that is there a more intelligent way of defining tables than by specifying table1col, table2col, table3col, tabl4col, ... table20col in the EDD and then specifying in the R/W rules the column attribute for each one. I have to leave room for user flexibility in the future for whatever table structure might come up. Is my only resort to define 20 or so table types with varying column attributes in the r/w file?

The intention is to make things as simple and small as possible. One potential problems is if I want to search tables in my database of xml and f/m files, do I then need to keep track of how many columns are in each table to be able to find a particular table in a search or even to find that table when I need a cross reference to it in a huge list of tables. My database may potentially contain hundreds of tables and keeping track of the column count to search for tables is not desirable. Further, the users of my f/m structure will not want to see all this clutter when they are building the document. It makes sense then to have only one table element instead of the 20 table types (table1col, table2col, table3col, ... table20col) in my EDD. I mean if I can perhaps define a table with 100 columns and just lop off empty columns in the conversion to xml that might be a possible alternative but I have no idea how to do it?

Hank

Hank,

I think Martti is trying to say the same thing I was earlier. If you are using FM as your authoring tool, and your read/write rules are set up properly, FM will automatically write this attribute for you when you export XML. In that way, you only need one table element. You won't need to explicitly declare the column number in the element name or r/w rules.

When you import XML into FrameMaker, it will read the number of columns in the attribute (rather than from your read/write rules) and generate the table properly. If your XML was generated from some tool other than FrameMaker, you'll simply need to run it through a simple XSLT transform to add that attribute. If you are using FM 7.2, you can make this xform part of the structure application.

Those r/w rules I sent you were intended to demonstrate the syntax. I use those rules to import/export tables with any number of columns.

Russ

Hi Russ,
After much of scratching my head, I finally figured out what you were trying to say and I did manage to get these tables worked out. Thank you and Martti for your kindness.

Hank