Conditional Text and Import by Reference - How?

[_Vern_McGeorge_]

I am working on a manual that uses examples from three different scripting languages. Conditional text is used to produce each version of the manual for each specific language. The client wants to move these code fragments out of the manual and maintain them in a form that can be executed and tested - thus the code needs to be imported from external text files.
The only problem is that there is a defect in FrameMaker (IMHO) which causes the conditional text information to be lost when a fragment is modified and re-imported. I am using the Convert from Text option.

If I had to guess, I would guess that Text is assumed to be featureless (i.e. lacking in conditional text capabilities) and that FrameMaker won't by design, reimpose whatever the setting were on the old content to the new content.

This leaves me with the thankless task of resetting the conditional text on my examples every time they change - Ugh!

Is there a way I can fix this?

An ideal solution would not require any changes to the imported fragments. A less ideal solution would required me to add meta-data to the fragments (which are generated automatically) as long as that meta-data could be expressed in some ASCII wrapper around the content.

[Russ Ward]

Vern,

This would be relatively straightforward with structured Frame, using attribute values to denote conditions. You could have container elements assigned to whatever output you wanted and import the fragments into them... the structural markup would remain permanent and available for conditional content management.

Russ

[Arnis Gubins]

Vern,

Are the code "fragments" complete stand-alone blocks that are imported
as separate insets, or it is one inset with threaded conditionals?

If it's the former, then you can conditionalize the insets themselves
and if they are imported by reference, then there shouldn't be any
further requirements to manipulate them inside FM.

[_Vern_McGeorge_]

Arnis,

The code fragments are separate insets. Before update, the Conditional Text Settings for the inset look something like this:

Current Selection Is:
( ) Unconditional
(*) Conditional
Condition Tag:
In:
JavaScriptCondition

Not In:
AppleScriptCondition
VBSCriptCondition

As Is:

After the inset is updated, the Conditional Text Settings looks like this:

Current Selection Is:
( ) Unconditional
(*) Conditional
Condition Tag:
In:

Not In:

As Is:
AppleScriptCondition
JavaScriptCondition
VBSCriptCondition

which, despite the radio button setting, is effectively unconditional.

I agree with you that there shouldn't be any further requirements to manipulate these insets inside FM - but there is.

[Arnis Gubins]

Vern,

I just checked this out and I think you've stumbled across a bug.

If the inset is in a larger block of conditionalized text and then
gets updated, FM breaks the condition at the start of the inset and
then restarts it at the end of the inset when the inset gets updated.
This is happening for all versions tested (v.7.0, 7.1, 7.2 and 8.0).

FM should be updating the insets independently of the conditional
settings.

[_Vern_McGeorge_]

If anyone can confirm that my "...guess that Text is assumed to be featureless (i.e. lacking in conditional text capabilities) and that FrameMaker won't by design, reimpose whatever the settings were on the old content to the new content" is true, then my next questions would be:

Is there an alternate filter (other than Text) that would allow the content of these fragments to be wrapped in other ASCII text (an XML like syntax comes to mind) that would allow me to re-assert the correct Condition Text Settings?

[Russ Ward]

Arnis, do you really think it is a bug, and not by design? It seems that you would want referenced content to come in as-is, without any assumptions such as conditional settings. I suppose if it is pure text, it makes sense to retain the formatting/etc. of the surrounding text, but may it's a bit much to ask for the distinction in this case.

I did a little experiment on something similar... I made a paragraph green with a format override, then inset some text into the middle of it. The text itself came in green, but the fragment of the original paragraph after the inset lost the coloring. So, it seems that the behavior is inconsistent and/or unreliable in any case.

Russ

[Lynne A. Price]

Arnis,

Annoying as this behavior may be (I, too, have wished for condition tags to remain after updating text insets), I do not believe it is a bug. It is parallel to pasting unconditional text over conditional content.

--Lynne

[Arnis Gubins]

Try this.<br /><br />Make a range of three paragraphs conditional, with the middle<br />paragraph anchoring the inset (regardless of length). Now update the<br />inset. Suddenly only the first and last paragraphs are conditional,<br />while the inset has been made unconditional.<br /><br />So if I've wanted the block containing the inset to be conditional,<br />why should FM make it unconditional for me?<br /><br />This is best seen in a MIF file (compare before and after an inset<br />update). You can see exactly where the <Unconditional> tag gets<br />inserted immediately before the updated inset, and the corresponding<br /><Conditional <InCondtion...> > tags get inserted immediately after<br />the inset. So FM is then breaking a contiguous block of a condition<br />when doing the update and re-inserting the inset in an<br />unconditionalized state. <br /><br />This is completely incorrect to what was originally tagged in the<br />file. If that behaviour isn't a bug, then I don't know what else you'd<br />call it.

[_Vern_McGeorge_]

Russ, Lynne,

Do try this at home ... 1. Select a reference and set the font size to something crazy like 30 pts. 2. Go make a noticeable change to the source file. 3. Update the reference. Note that the 30 pt. font size is retained but the conditional text settings are lost.

I can see the assumption that text should perhaps come is "as-is" but retaining some attributes while losing others is just plain broken.

Given how useful it would be keep the conditional text settings, FM should at least offer a choice of what to retain and what to lose on import.

[Russ Ward]

I think the debate on whether it should or shouldn't can go both ways, especially as an unstructured document lacks the metadata to really specify the desired outcome. Vern, if this is important to you, consider moving to structured documents. They will give you the capability to merge content reuse techniques like this without ambiguity and unexpected FM behavior.

Russ

[Arnis Gubins]

Russ,

In what I see, it doesn't matter whether things are structured or
unstructured, FM in this situation is fundamentally changing the
characteristics of a user-defined container. That's a no-no in my
book.

[Russ Ward]

Arnis,

I would counter that there really are no clear characteristics of the container, and in fact, there really is no defined container at all. One particular user might regard a conditional section of text as a "container," but it really is only in the user's mind... there's nothing explicit in the document to clearly define a container and its characteristics. We might expect Frame to guess at our intention to have the condition tags of the surrounding text applied to an inset, but this would only be an assumption that might not work in all cases. For example, what if you imported at the exact boundary of two condition tags, or at the exact boundary of two character format tags, or both? Where is the container in this case?

I can see where you would expect a pure-text import to get all the formats and conditions of the surrounding text. But I still don't think it's necessarily a design flaw that it does not. An unstructured document simply lacks the architectural intelligence to make a clear decision on exactly what should happen.

Russ

[Arnis Gubins]

Russ,<br /><br />Are you saying that a paratag or character tag can't be considered a<br />"container" in an unstructured document? The text inset has to be<br />placed inside of something - it is just an object. The conditional<br />range (start and end of a condition indicator) can also be considered<br />a "container", because that in effect is what one is doing in an<br />unstructured document when inserting condition tags - one is binning<br />or applying a type of structure to the document [let's not argue over<br />the semantics here, just acknowledge the concept that user has defined<br />some sort of container that holds an object and has expectations that<br />it, the container, will not be altered without permission].<br /><br />The condition range and paragraphs themselves are the containers in<br />this case with the situation like (very idealized) this:<br /><br /> <condition on><br />Paratag + contents<br />Paratag + text inset + contents<br />Paratag + contents<br /> <condition off><br /><br />The condition that the user has defined applies over the entire range<br />and includes the whole of the text inset. There is a clearly defined<br />range/container in the content that the condition is specified to<br />exist.<br /><br />However, whenever FM updates the inset (be it automatically when FM<br />opens the document again or manually at the user's discretion), the<br />following is how it now occurs (and can clearly be seen in a MIF when<br />looking at before and after):<br /><br /> <condition on><br />Paratag + contents<br />Paratag <condition off> + text inset + <condition on> + contents<br />Paratag + contents<br /> <condition off><br /><br />So FM now breaks the user's originally specified range/container for<br />the conditional setting. <br /><br />Why would you even expect there to be a requirement for "a clear<br />decision on what should happen"? FM shouldn't be doing anything except<br />updating the inset contents in this situation. ;-)<br /><br />Bug or feature? I still say that this is a bug.

[Russ Ward]

Arnis,

I'm not saying that paragraph, character, and condition tags can't be considered containers, I'm just saying that there are an endless array of ambiguities that can result and that I wouldn't consider it a software flaw if FM did not guess right and account for the one I wanted at the moment. These tags can overlap in any conceivable permutation making the concept of a container a bit fuzzy. One "container" can contain any number of parts of any other container, which would make it very difficult for a developer to put in place a logical and reliable set of rules for "container" handling. It would be like having a bunch of buckets where any one bucket could contain a fraction of any other buckets, and then telling someone first to figure out what any bucket really is and then painting only one of them blue.

Getting back to my original point, this is why structured content is so useful and can completely eliminate this ambiguity. In the case of XML-like structure, an element is a clearly-defined container whose whose boundaries cannot span across the boundaries of another element. You (and the software) know exactly where the containers are and what they contain. Furthermore, you can add any amount of specific, descriptive metadata to an element container to facilitate things like container management for content reuse.

This is an interesting debate that has certainly strayed into some gray areas. One thing I do know, though... if Vern were to use structured documents and abandon the more primitive reuse features based on ambiguous text range containers, the original problem and its fundamental cause could be solved.

Russ

[Arnis Gubins]

Russ,

I disagree that FM's developers have to make guesses about what is
intended. The user has already indicated what is desired, and the act
of including updated content for any object (be it a word, a
paragraph, an anchored frame or a text inset) should not break what
the user has defined.

In my mind, this behaviour is identical to having structured FM
arbitrarily decide that a user-specified attribute should not be
honoured in a particular tag, e.g. if color="red", then FM says.
"Color, what color? You can't have any.", when the content of that tag
changes. You'd be screaming bloody murder if this happened to you and
probably wouldn't hesitate to call it a bug.

I'm not arguing about the fact that a structured environment would
define things more clearly (I do agree on this point!), and that there
could be overlaps of conditions. But the behaviour of FM in ignoring
what the user has specified by simply turning off all conditional
settings for any type of inset is plain wrong.

FM should not be doing anything in this case and simply leave things
as they are. Laissez-faire; let sleeping dogs lie; butt out; etc.

Yes, if Vern were to convert to a structured authoring environment he
would be able to solve his dilemma, or he could try a FrameScript
solution or even an automated publishing solution like Miramo or
Patternstream, but regardless of the route, it's going to cost him a
pile of time and money to work around a BAD (broken as designed)
programming decision in FM.

'Nuff said on this.

Arnis

[Russ Ward]

Fine. Have Adobe add it as bug #1702705 :)

[_Vern_McGeorge_]

Russ,

I understand that in unstructured frame that there is no explicit container outside of the user's mind and I trust that from an implementation point of view, the current implementation makes sense.

From a user point of view, however, it does not. I can apply some characteristics (font size, paragraph style) that persist across import but others (conditional text) are lost which sort of undoes most of the value of automatic update.

Expecting frame to apply the characteristics of the text surrounding an inset is probably not correct either.

What I would like frame to do is to keep the characteristics that I have applied to an inset when the contents are re-imported. Since clicking anywhere in an inset selects the whole thing it's already clear that frame knows its boundaries whether or not there is a container - so there shouldn't be any weird edge conditions to make things break - no architectural intelligence is required.

This is one of the cases where slightly different processing steps ("replace the contents of the text inset with the contents of the file" vs. "replace the text inset with a new text inset constructed from the file") would yield more consistent, predictable, and very useful results.

-- Vern