unwanted transformation

[FieryPantone]

FM 8.0p273

1. I prepare an xml file (in a text editor) which includes lines such as
[checklist status = "unchecked"]restricted (not all information made available)[/checklist]

2. I validate the file against its DTD

3. I open the file in FrameMaker with its matching application - no errors

4. I click on Save and get a whole slew of errors "The attribute 'status"' is already used in the element 'checklist'"

5. Though the file has not been saved, the text editor warns me it has been changed externally; when I reload the file in the text editor, I see that
[checklist status = "unchecked"]restricted (not all information made available)[/checklist]
has been consistently garbled to
[checklist status = "unchecked" status = "unchecked"]restricted (not all information made available)[/checklist]

If this is something to do with r/w rules, it's far too clever to be something I've done myself :-}

I'm off on leave for a month starting tomorrow, but will follow up and hints and tips as soon as I get back; thanks in advance.

N

[MarttiP]

Hi N,

What does your DTD say about this element's attribute definitions? and also what is in r/w rules for this element?

I assume that using frame's Element->Validate command returns valid document.

It looks like the status with value "unchecked" is a default value written either by the parser or by rw rules and the edd allows user to add status attribute (remember, edd has no direct knowledge of the underlying dtd and/or rw-rules).

Martti

[Lynne A. Price]

N,

Your message raises several issues:

1. 
   
2. If you leave a document open in one application (your text editor, for example), and then open it and save it in a second application (FrameMaker, for example), it is not surprising that the first application reports that the document has been "changed externally".
   
3. 
   When you open an XML document, FrameMaker interprets the defined structure to build a structured document. When you save a structured document as XML, it creates a new XML document with the same element structure as the FrameMaker document. This representation of an element structure in either XML or FrameMaker was evident in FrameMaker 7.0, in which an opened XML document resulted in an unsaved FrameMaker document with the same name as the XML file but the extension changed to .xml. Saving the result created a binary FrameMaker file. For example, opening test.xml and saving the result created test.fm.

   Since FrameMaker 7.1, however, under the default configuration, when you open an XML document, FrameMaker retains the original filename, complete with extension, and when you save the document, FrameMaker creates a new XML representation of the element structure, saving that under the original name and thereby overwriting the original document.
   

   Presumably, this change saves end users the effort of keeping track of separate XML and FrameMaker versions of a file. Even if there are no problems with the XML application you are using, however, opening an XML document in FrameMaker and saving the result is very unlikely to result in an XML document that is character-for-character identical to the original. There are many details of an XML document--order of attributes within a start-tag, some line breaks, etc.--that are incidental to the represented element structure and may not be preserved when you round-trip an XML document through FrameMaker.
   

   Opening an XML document can result in a FrameMaker book. Such a book is always stored in FrameMaker form unless you explicitly save it as XML.
   

   You can restore the FrameMaker 7.0 behavior on Windows by adding

   TreatXMLAsXML=Off

   to the Preferences section of maker.ini. See the Structure Developer's Guide for the UNIX equivalent. (Make sure to exit FrameMaker before editing maker.ini.)
   

4. Depending on the configuration of your application--template, DTD, read/write rules, custom API client--moving an element structure in either direction between XML and FrameMaker can produce an invalid result from a valid original.
   
5. When moving an element structure from XML to FrameMaker, a typical XML attribute becomes a FrameMaker attribute. When an XML element corresponds to a special FrameMaker formatting object such as a graphic, cross-reference, or table, some attributes instead correspond to FrameMaker formatting properties. For example, the XML representation of a table may have an attribute for the number of columns in the table. There is no need in FrameMaker for such an attribute; the number of columns in the table is an inherent part of a FrameMaker table. Storing this information in a FrameMaker attribute would therefore be redundant and it would mean that the attribute value would need to be changed each time an author added or removed a column. Instead, therefore, when FrameMaker opens the XML document, it uses the XML attribute to create the represented construct, but does not save the original value in a FrameMaker attribute. When FrameMaker saves the FrameMaker document as XML, it creates XML-only attributes to store necessary property values.
   

   Read/write rules control various options involving the representation of FrameMaker properties as XML attributes, including the names of the attributes used. In many cases, the default behavior is adequate and no read/write rules are necessary.
   

   If a FrameMaker document has attributes that have the same name as the attribute used to represent a property, FrameMaker can write both the value of the FrameMaker attribute and the value of the property to the same XML start-tag. For example, suppose a four-column table has an attribute named cols with the value "2". FrameMaker might generate a start-tag such as <table cols = "2" cols = "4">. Even if the attribute and property values are the same, it will still write both: <table cols = "2" cols = "2">. Such erroneous XML results from incompatible details of the FrameMaker document, DTD, and read/write rules.
   

--Lynne

[FieryPantone]

Touching base for a day before disappearing for another three weeks... thanks for the input!

Lynn, I'll mull over your thorough comments; from point 4, it seems (and doesn't altogether surprise me) I still have a lot to learn about tables; up till now, I'd thought I understood that I _had_ to have colnums information in the xml file.

As for point 1, the useful "file changed by external app" message is just what I was expecting to see.

Onward ... but not just yet ;-}