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
[EMAIL PROTECTED]http://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284
___
You are currently subscribed to Framers as [EMAIL PROTECTED]
Send list messages to [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
or visit
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com
Send administrative questions to [EMAIL PROTECTED] Visit
http://www.frameusers.com/ for more resources and info.
RE: Read/write rules question - retaining markup attribute
At 09:41 AM 10/20/2006, Daniel Osborn wrote: Thanks, it works perfectly. The name of the table format and the attribute value are the same, so no problems there. Daniel, Just remember that it is the user's responsibility to keep the attribute value and table format the same. --Lynne Lynne A. Price Text Structure Consulting, Inc. Specializing in structured FrameMaker consulting, application development, and training [EMAIL PROTECTED]http://www.txstruct.com voice/fax: (510) 583-1505 cell phone: (510) 421-2284 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Read/write rules question - retaining markup attribute
Hi, I'm trying to set up the read/write rules for my XML files and have run into a problem. I've cheated a bit with DITA and am using the 'otherprops' attribute of 'table' to store the table format. I'm using this rule: attribute otherprops is fm property table format; I set this attribute in Frame and also select the corresponding table format (the same value). When I open the file in FM the attribute value is lost, and the table is formatted correctly. I looked in the structured developers guide and found that this is as designed: 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. I could misuse another attribute and store my value in one, and the FM table format in another. But I'd rather keep the misuse to a minimum. Any ideas? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Read/write rules question - retaining markup attribute
Hi, I'm trying to set up the read/write rules for my XML files and have run into a problem. I've cheated a bit with DITA and am using the 'otherprops' attribute of 'table' to store the table format. I'm using this rule: attribute otherprops is fm property table format; I set this attribute in Frame and also select the corresponding table format (the same value). When I open the file in FM the attribute value is lost, and the table is formatted correctly. I looked in the structured developers guide and found that this is as designed: 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. I could misuse another attribute and store my value in one, and the FM table format in another. But I'd rather keep the misuse to a minimum. Any ideas? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Read/write rules question - retaining markup attribute
Hi, I'm trying to set up the read/write rules for my XML files and have run into a problem. I've cheated a bit with DITA and am using the 'otherprops' attribute of 'table' to store the table format. I'm using this rule: attribute "otherprops" is fm property table format; I set this attribute in Frame and also select the corresponding table format (the same value). When I open the file in FM the attribute value is lost, and the table is formatted correctly. I looked in the structured developers guide and found that this is as designed: 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. I could misuse another attribute and store my value in one, and the FM table format in another. But I'd rather keep the misuse to a minimum. Any ideas? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office
Read/write rules question - retaining markup attribute
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.comhttp://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284
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.comhttp://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284
Read/write rules question - retaining markup attribute
At 09:41 AM 10/20/2006, Daniel Osborn wrote: >Thanks, it works perfectly. The name of the table format and the >attribute value are the same, so no problems there. Daniel, Just remember that it is the user's responsibility to keep the attribute value and table format the same. --Lynne Lynne A. Price Text Structure Consulting, Inc. Specializing in structured FrameMaker consulting, application development, and training lprice at txstruct.comhttp://www.txstruct.com voice/fax: (510) 583-1505 cell phone: (510) 421-2284
Read/write rules question - retaining markup attribute
Hi, I'm trying to set up the read/write rules for my XML files and have run into a problem. I've cheated a bit with DITA and am using the 'otherprops' attribute of 'table' to store the table format. I'm using this rule: attribute "otherprops" is fm property table format; I set this attribute in Frame and also select the corresponding table format (the same value). When I open the file in FM the attribute value is lost, and the table is formatted correctly. I looked in the structured developers guide and found that this is as designed: 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. I could misuse another attribute and store my value in one, and the FM table format in another. But I'd rather keep the misuse to a minimum. Any ideas? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office
