Hi Lynne, Thanks, it works perfectly. The name of the table format and the attribute value are the same, so no problems there.
The reason I want to do it is that I format the text in the table based on the type of table it is. It's not that much work to enter this information - every time I choose to enter the element 'table', I specify that attribute from a list of choices, then specify the table format in the next dialog. The real reasoning behind all this is that I am misusing DITA a bit in another way: rather than use the 'note' element for notes, I am using tables. The style guide says that notes should be in a gray box using italic font. I found the easiest way to do this in Frame is to put the note in a single cell table. The table format creates the gray background, I set 'otherprops' to 'note', and then test the 'otherprops' attribute to format the text. I do this with a couple of different types of tables, mostly when they are used for formatting. If anyone has any other suggestions to cope with this, I'd love to hear them. Many thanks for your help, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office -----Original Message----- From: Lynne A. Price [mailto:lpr...@txstruct.com] Sent: Friday, October 20, 2006 5:56 PM To: Daniel Osborn; framers at lists.frameusers.com Subject: Re: Read/write rules question - retaining markup attribute At 09:13 AM 10/19/2006, Daniel Osborn wrote: > If you use the is fm property rule to translate a markup attribute to >a FrameMaker property, the markup attribute does not also appear as a >FrameMaker attribute. > >My question is, is there a way to do this so that the markup attribute >does appear as a attribute of the element in Frame. I'd like to keep >this value so I can test it in the edd and format the text in the table >accordingly. Daniel, Why do you want to do so? The information is stored in both the FM and XML representations of the document. As you've described, when you open an XML document, FM uses the attribute value to set the table format. When you save the FM document to XML, FM will export an attribute. If you map the XML attribute to an FM attribute, there's no way to keep the table format in synch with the attribute value. When you insert a new table in a document, the Insert Table dialog box will appear, allowing you to select a table format. Short of a plug-in or FrameScript, there's no way to ensure that the selected table format is the same as an attribute value. Furthermore, you can always change the format of an existing table within FM. Again, there's no way to validate that you've changed an attribute value as well. Nevertheless, if you really want to do so, you might be able to use the rule: attribute "otherprops" { is fm property table format; is fm attribute; } If this does work (and I don't have time to test it now), I suspect the actual table format rather than the attribute value is used on export. --Lynne Lynne A. Price Text Structure Consulting, Inc. Specializing in structured FrameMaker consulting, application development, and training lprice at txstruct.com http://www.txstruct.com voice/fax: (510) 583-1505 cell phone: (510) 421-2284