Unexpected change to Attribute Values (FM2019)

[QuintinSeegers]

A strange thing happened to our documents recently.

We have an optional Attribute against one of our Elements, with 5 values users can select from. The Attribue value drives context formatting rules.

We use a master document to import (File > Import > Formats) generic settings, selecting all options except Filter by Attribute Settings, Variable Definitions and Conditional Text Settings. After a recent import, all instances of the above Attribute was changed to the a specific value. The value they were changed to is the second last in the available options and not the default.  (We now have the joyous task of correcting the 500+ instances of the Attibute.)

Any thoughts as to how/why this happened?

[Russ Ward]

Hi Quintin,

This clearly should never happen and I'd be really interested to know if you can replicate it.

For changing the value back, the FrameMaker Find/Change dialog seems to have the ability to do it automatically. I have not ever tested it personally, but the option is there.

One thing to note about FrameMaker... a default attribute value is odd. I'm not sure exactly how to explain it, but it is not really there. You'll see that it initially appears in italics. Then, if you actually set it purposefully with an attribute editor, it changes to regular text. So in some weird way, it is kind of "fragile" until actually purposefully set. For example, if you export to XML without setting it purposefully, the value does not export. That is a terrible explanation but I really don't know much more about it or why it is that way. Maybe somebody else can provide more insight.

But anyway, an import of formats still should not change anything. I'm interested to know if you can replicate it.

Russ

[QuintinSeegers · Accepted solution]

Hi Russ,

It is rather baffling. We luckily picked it up during the proofing process. I haven't been able to replicate the problem, which makes it difficult to troubleshoot.

I agree the default attribute value 'setting' is a bit 'flaky' in that it shows the value in the Structure View, but when you open the Attributes pod, it's blank. We use this 'default' value to save our writers from having to select the most common value - they only need to select something if it needs to be different from the default. We don't use XML (yet), so we're ok on that front (for now).

Our documents have been through the ringer in recent months, being converted from unstructured to structured FM, scripts run on them to tidy up the elements, various changes to the EDD, etc. I won't be surprised it something happened during all those changes, causing it to go wayward when we recently imported the formats.

If no-one else has come across, this, I'm happy to write it off as an anomoly due to something we've done.

Quintin

[Lynne A. Price]

Quintin, Russ,

   I have to disagree with you about default attributes being odd or flaky. As is true in many applications, the default value of a FrameMaker attribute is the value that FrameMaker uses when the user has not specified a value for the attribute. This type of processing is exactly what is expected for XML tools.

   As far as showing the default value in the Structure View, if an attribute value is not set, FrameMaker displays it, but, as Russ pointed out, in italics. Thus, the user is informed both that no value has been specified and what value FrameMaker will use. The user needs to know this convention, but that is true of all sorts of display conventions.

  It is possible to do a global Find/Change to change attribute values. Doing so does not reformat the document, so for attributes that affect formatting, the user must import element definitions to reapply format rules after such a global change.

  When saving a document as XML, FrameMaker does not export a value for an attribute that has not been set, regardless of whether there is a default for that attribute in FrameMaker. Thus, the FrameMaker and XML attributes are consistent and can be round-tripped. Use XSLT if you desire them to be different.

   --Lynne

[QuintinSeegers]

@Lynne A. Price Thanks for your valued input, as always.

Unfortunately, using the global find/replace won't correct the attributes, as in the same document different instances of the element could have different attribute values. Thus using the global find/replace to correct the Attribute would simply replicate the issue - assigning the same attribute value to all instances of the element.

We don't use XML, so I'm not too worried about the impacts of default attribute values when saving to XML.