cross reference behaviour which I don't understand

[Trevor-Nicholls]

As other threads have already covered, I've been updating an application from FM8 to FM2019 and I've just noticed what appears to be a change in behaviour that I'd like to understand.

When a user opens one of our XML documents in Frame, a pre-processing stylesheet is run which "expands" the document, pulling in the content of "included" sub-documents. This means that instead of having perhaps twenty-five separate tabs containing separate parts of a document, the user is able to edit in a single tab. When they save their changes, a post-processing stylesheet "collapses" the document into its constituent parts.

So if (say) the original document a.xml contains the element

<include srcfile="b.xml"/>

then the preprocessing step transforms this into

<included srcfile="b.xml">

  <document..><title id="b1">Document B"</title>...</document>

</included>

Frame presents the user with what appears to be a single document, and the structural view shows an "included" element wrapped around the content extracted from the sub-document.

So far so good. The problem relates to the situation where the user wants to create a cross-reference and point it to the beginning of the included content.

In FM8 they would insert a cross reference, select from the current document, pick "title" from the element tag list, and then pick "Document B" from the matching element list. The resultant XML when the document was saved was valid, and it would round-trip. This absolutely worked, we relied on it all the time.

In FM2019 it seems to be a bit different. I go to insert a cross reference, pick "title", but now for some reason the element list contains the actual text of every title in the parent (wrapper) document, but any title in an included document appears in this list as "Included: b.xml Document B". I can select this element to link to, which puts that "included: b.xml Document B" string in the document view (ugh), but that's not the half of it. When I save the document it does not round-trip, and on opening the document again it reports

XML Read Messages (Document instance)

No cross-reference ID specified for the element (link).

Can anyone explain what is going on here?

cheers

T

[Trevor-Nicholls]

After a bit more research, I have a slightly better idea of what is going on, and the description in the initial post is not quite correct.

When inserting a cross-reference from the current document, it is only the first title in each "included" subfile that is prefixed in the element list. So if (to extend the example used above) we had

<included srcfile="b.xml">

<document><title id="b">Document B</title>

  <section><title id="b1">Section B.1</title>...</section>

</document>

</included>

then the reference insertion list would show

Included: b.xml Document B

Section B.1

From this list I can pick "Section B.1" which will insert the correct cross-reference, and allow me to save a document which will round-trip without errors. But I cannot pick "Included: b.xml Document B". What confused me was that "Included: b.xml Document B" was highlighted in the list when it opened because the document I was editing already contained that cross-reference. But I could never actually select it; what was happening was that I was closing the dialogue without changing the link, and the id was being stripped from the cross-reference when the document was saved.

I can also see where the "Included: b.xml" prefix is coming from. The formatting rules in the EDD include a prefix for the title:

Prefix rules

1. If context is: document < included

    Prefix: Included: <$attribute[srcfile: included]>\r

    Text range.

      etc...

At this point I'll reiterate that there must have been a significant change since Framemaker 8; FM8 presented the title without a prefix in the reference element list, and allowed the user to select it. FM2019 presents the title together with its prefix in the list, but does not allow the user to select it.

You could argue either way whether the prefix should be included or not, but not allowing the user to select the element when it has been offered in the list is clearly incorrect.

[Trevor-Nicholls · Accepted solution]

Final post on this: the reason the title isn't selectable is that including the full prefix in the title text makes it too wide for the dialog in which it appears; when the user moves the cursor over the title a new layer is superimposed over the selection list so that the user can see the full value, but can't select the title in the list behind it.

Moving the prefix onto another element avoids the problem entirely, so that's what I've done.