Skip to main content
Participating Frequently
May 26, 2014
Question

XML Attributes Created Twice in the XML after Saving in FM

  • May 26, 2014
  • 1 reply
  • 786 views

Hi All,

I've built a structured application to read and write a custom XML. The file is opened just fine. However, when saving the XML in FM, some XML attributes appear in the XML twice. For example, in the original XML I have the following:

<object_group doc_name="xxx" parsed_by_sym="false">

...

</object_group>

After I save the XML, it looks like this:

<object_group doc_name="xxx" parsed_by_sym="false" doc_name="xxx" parsed_by_sym="false">

...

</object_group>

After the XML is saved, FM refuses to re-open it aborting the parsing. If I remove the doubled attributes manually in Notepad, then the XML is opened in FM again.

Should I define anything in read/write rules? What am I doing wrong?

I'm using an XSD, which I defined in structapp.fm.

Thank you very much!

This topic has been closed for replies.

1 reply

Inspiring
May 29, 2014

Alex,

    I don't have time to do any testing, but if I remember correctly, I've seen attributes doubled in start-tags in two situations:

1) The behavior may be temporary and corrected by relaunching FM or rebooting your system.

2) If the attributes exist in the FM (WYSIWYG) view of the document and there is a r/w rule that maps the attribute to an FM property (such as the width of an anchored frame or a table format), FM may write out the attribute once while processing the attribute in the FM document and once when processing the property. There is usually no need to store attributes in the FM view when the attributes correspond to FM properties. For example, the number of columns in a table doesn't need to be stored in an FM attribute since the number of columns is an inherent part of FM's table model. R/w rules can associate the number of columns both with the property and an attribute. For example, an attribute called numcol can be used in this way with the rule:

attribute numcol {

    is fm property columns;

    is fm attribute;

    }

In this case, however, changing the attribute values doesn't effect the number of columns in the table. It therefore may be confusing to show the attribute in the FM view.

This problem can arise when you create your EDD from a DTD before creating r/w rules that associated attributes with properties, or if you change r/w rules after creating the FM document but before saving it as XML.

--Lynne

Participating Frequently
May 29, 2014

Hi Lynne,

Thank you very much!

For one of the tables, I have exactly what you said. It's an attribute that defines the number of columns. In my read/write rules, I have exactly the same piece of code that you gace in your comment. I have a question, though: when you say "There is usually no need to store attributes in the FM view when the attributes correspond to FM properties", do you mean that I shouldn't define this attribute in the EDD? Or how else I make an attributed not to be stored in the FM view?

Many thanks,

Alex

Inspiring
May 29, 2014

Alex,

   Define the attribute in the DTD, but do not define the attribute in the EDD. If the attribute is called x, in the read/write rule for the table element, include the following subrule:

       attribute x is fm property columns;

  The idea is that you need the attribute in XML because the information isn't stored elsewhere, but you don't need the information in FM because FM has already created a table with some number of columns.

  I don't know how your EDD and DTD are related, but with the above r/w rule, if you automatically generate an EDD from a DTD, FM does not declare the attribute in the generated EDD. Similarly, if you automatically generate a DTD from an EDD that does not define the attribute, the r/w rule tells FM to declare the attribute in the generated DTD.

--Lynne