🚀 go-pugleaf

Hi soundworkz,

What table DTD are you using, CALS or OASIS?. It is crucial that the number of columns is correctly translated from XML attribute to framemaker columns property. Missing column info causes frame to collapse cells in one column + tons of error messages.

Make sure that you structapps.fm has correct application settings to use correct rw-rules. If you export XML from frame file, make sure that frame is using correct application (File->Set Structured Application). The application can be also defined in the EDD.

Hope this helps,
Martti

Hi,

since you are not using default element names you have to add r/w rules for table heading/body/footing elements, table row and cell elements too, to tell FrameMaker, that it should treat the elements accordingly.

- Michael

That is true. And with that, it should work, especially because you have the all-important columns property on the table element. I'm at a loss to explain why none of the other rules are working, though, with regards to the case change. These are simple rules that shouldn't cause any trouble. The syntax looks right ro me.

If I simply open the xml file in Internet explore, that is how the xml file is supposed to look right because when I open it in framemaker, it takes my xml file and converts the file into a nice doument with pictures and everything. That is not the actual xml file. Correct? Also, with the columns property, does that mean, that in my EDD file, I need to define tables separately for those with 4 columns and 5 columns adn so on, if I want to ultimately take my .fm file and convert to a xml type document. Thanks

Hank

Hank,

For your first statement, that is correct. What you are looking at post-import is FrameMaker's rendition of the XML, according to any modifications that the read/write rules made and formatting that the EDD applied. Practically speaking, it's an FM document at that point.

From an authoring standpoint, this aspect of Frame XML import is one of its great strengths. It allows you to add formatting and all kinds of nice stuff to the markup in order to make authoring more friendly. You'll often hear that there is no better XML editor from a user-friendliness standpoint, and despite all that Frame does lack, I would agree with that notion.

For your second point, that is not necessarily correct, unless you make your general rules particularly strict, which most people do not. That is, if you specify an exact number of table cell elements that a table row element can contain (in the EDD), this will effectively mandate a set number of columns (sort of). If you leave the number of cells optional, the table definition will apply to all tables. Note that this really applies to EDD-based validity only... Frame should still import a table according to the columns property setting, and if it happens to violate EDD rules, it will simply show it as invalid. It won't lop off columns just because the EDD says they are structurally invalid.

Russ

Russ,
I kind of understand what you are saying with the columns. So, I understand the EDD will accomodate any number of columns I specify when I place a table element in my frame document. but, this number is somehow lost in translation to xml unless specified in the read/ write rules. But, if I need my document to have tables of width 3,4,5 and 6, I don't see how I can do it without creating 4 different table elements in the EDD so I can identify them separately in my Read/ Write rules files to specify a different number of columns in my rules file. One other alternative (although I don't know if this can be implemented or not) is to set the number of columns high and tell frame in the R/W file to lop off columns with empty cells so the minimum number of columns for a table is always displayed. What do you think? Thanks

Hank

Hank,

Taking a closer look at your rules, I see where you are coming from now. The way you have your rules set up, I think you are right. However, if you have control over your schema/DTD, there is a better way to do it, by having Frame automatically count the number of columns and store that value in an attribute. Here's an example, from a set of rules that I use:

element "table"
{
  is fm table element;
  attribute "refcols"
  {
    is fm property columns;
  }
  attribute "format"
  {
    is fm property table format;
    implied value is "parmstable";
  }
  attribute "relcolwidth"
  {
    is fm property column widths;
    implied value is "2in 2in 2in 2in";
  }

}

With these rules, the number of columns is automatically stored in a "refcols" attribute when I export to XML. Furthermore, the table format and column widths are also stored in attributes. Then, when I read the XML back in, these values are converted back to FrameMaker properties. If the XML never came from FrameMaker to begin with, that's OK too... just as long as the number of columns gets into that attribute somehow.

The attributes don't exist in FrameMaker (in the EDD). They only exist in my XML schema. With these rules, Frame automatically creates them on export, and discards them on import. Naturally, you will need to allow them in your DTD/schema, or the XML validation will fail.

Let me know if that makes sense.
Russ

Thanks Russ. Your a lifesaver. Let me try to let all this soak in and check it out later.

Hank

Can you explain what is xml schema and how do I work with it? I used my EDD file to generate the DTD file, but when I open my DTD file I get the error

Error at file c:\Program Files\Adobe Framemaker 7.1\structure\xml\docDTD, line 9, char 2, Message: Expected comment or CDATA.
Error at line 13 char 1, Message. The element stack is empty.
Parse error at line 9, char 0. Syntax error.
Parsing aborted.

I am not sure where I would add those comments above. I tried putting them in my Read Write file and saved everything as xml. When I opened my xml file, I get a bunch of these errors

Framemaker cannot insert the table cell (TCell) at the current position. A cell must be in a table row. I'm still very much stuck on how to do this. Any advice? Thanks

Hank

Hank,

For your table problems, you need to have your rules set up, with each table component element declared explicitly. And you need to have that column number attribute. I'll email you a rules file that I use and maybe that will give you some idea.

For your DTD, I don't know offhand. The Save As DTD thing isn't always perfect. You probably need to get an XML editor to open it up and perfect it manually. A good XML editor will be able to provide better information on DTD syntax problems.

"Schema" is an alternative to a DTD for defining an XML structure definition. It was invented by Microsoft (I think) and later adopted by OASIS. It provides an enhanced feature set for XML validation, but is more complicated to understand than a DTD. Only FM 7.2 supports schema validation for XML export, and it still doesn't support any comparable features to the DTD management tools, such as Save As DTD.

Russ