Skip to main content
J
Jeddleman
Inspiring
May 1, 2009
Answered

Variable Conversion to XML

  • May 1, 2009
  • 1 reply
  • 1453 views

Using: FM 8.0

I am exporting a structured fm file as XML and trying to setup my read/right (rw) rules to eliminate the characters that are placed around each variable when exported.

When I export a fm file as XML the words that were set as a variable within Framemaker are export with a preceding & and a trailing ;

For example if the word Cardboard is set as a fm variable, it appears like this when exported as XML:

&Cardboard;

Is there a r/w rule that would strip the “&” and the “;” away from these words during the export process?

Thanks in advance for everyone’s help.

This topic has been closed for replies.
Correct answer Russ Ward

Jeddlemen,

It sounds like you are using "unstructured" variables (ie, no element tag around them), which are converted to entity references when saved to XML, hence the &entity; notation. Although, I think the text should represent the variable name, not the actual value, and you should see something like the following at the beginning of the XML file:


<!-- Begin Document Specific Declarations -->

<!ENTITY Cardboard "Cardboard (or whatever value)">

<!-- End Document Specific Declarations -->

I don't believe that there is any way to suppress this behavior with r/w rules, aside from dropping the variables completely or simply changing the entity name. If the marker is structured, you can have it write the text to an attribute, but I don't see anything in the Structure Dev guide about writing it to the element text instead. It might work to structure your variables, then apply a simple XSLT stylesheet to the process to convert the attribute to element text, or just discard the element altogether and replace it with text. Note that the second option would remove the ability to reimport the content as a variable.

Russ

1 reply

R
Russ WardCorrect answer
Brainiac
May 1, 2009

Jeddlemen,

It sounds like you are using "unstructured" variables (ie, no element tag around them), which are converted to entity references when saved to XML, hence the &entity; notation. Although, I think the text should represent the variable name, not the actual value, and you should see something like the following at the beginning of the XML file:


<!-- Begin Document Specific Declarations -->

<!ENTITY Cardboard "Cardboard (or whatever value)">

<!-- End Document Specific Declarations -->

I don't believe that there is any way to suppress this behavior with r/w rules, aside from dropping the variables completely or simply changing the entity name. If the marker is structured, you can have it write the text to an attribute, but I don't see anything in the Structure Dev guide about writing it to the element text instead. It might work to structure your variables, then apply a simple XSLT stylesheet to the process to convert the attribute to element text, or just discard the element altogether and replace it with text. Note that the second option would remove the ability to reimport the content as a variable.

Russ

J
JeddlemanAuthor
Inspiring
May 2, 2009

Russ, thanks for your response.

I did fail to mention that the following line was also generated in the XML file:

<!-- Begin Document Specific Declarations -->

<!ENTITY Cardboard " Cardboard Box">

<!-- End Document Specific Declarations -->

Sorry about that.

I wanted to keep my XML file as clean as possible without declaring Entities, unfortunately it appears that there is no easy way to suppress this using r/w rules.

Thanks again for your help.

J
JeddlemanAuthor
Inspiring
May 4, 2009

Hi,

Local entity definitions in XML are not that bad since they get resolved by the XML parser and they don't require any external definitions, So they are quite "clean" in that sense.

BR, Martti


Martti, I agree with your comment. I should’ve elaborated on my reasoning for trying to keep the local entities from my xml files instead of implying it would invalidate them.

Thanks for that clarification.

JE

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices