How to retain xref formats when round tripping using DocBook v4.2

[elkev]

I want to round trip the xrefs and retain the format of a xref  where the format varies on whether the xref relates to a table, chapter, another topic, etc. For example, I want to retain something like this for an xref that refers to another topic: "Overview orf Something on page 1-2 describes ..... On the other hand, I would like to vary the xref for a table, e.g., Table 40 describes ..... The objective is to retain these cross reference formats during a round trip. We are using DocBook v4.2. I was told by our engineers that this cannot be done and one can only retain one format and cannot vary it. Has anyone had any experience with this issue?

See Overview of Something on Page 1-2 for your information. ...

I was told that this cannot be done because the script looks like this after it has been exported:

See <XREF ID="xxxxx"> for your information. ...

I was told the following by engineers that provided a custom plug-in:

Import/Export plug-in can't distinguish the type of referred object during importing according to engineers.

After you import the xml file it reads as follows

It’s impossible to vary cross-reference format based on referenced object types such as table, figure, things like that.

... See Overview of Something for your information. ...

[Michael_Müller-Hillebrand-basb]

What you experience is not a limitation of FrameMaker but maybe of your structured environment. Using R/W rules like the following it is possible to store the used cross-reference format as an attribute value in XML. It will then be used when opening the XML:

element "crossref" {
   is fm cross-reference element;
   attribute "idref" is fm property cross-reference id;
   attribute "format" is fm property cross-reference format;
}

In case an appropriate attribute is not available in XML, it would be an option to use XSL preprocessing to create that attribute just for FrameMaker, filled with values that depend on the context of the target element. If the target e.g. is a table you could insert the attribute with the name of the xref format you want. I use XSL preprocessing to select language-dependent xref formats based on a language attribute.

- Michael

[JohannesKrueger]

The xrefstyle attribute, which is intended to store the information, has been introduced for Docbook v4.3, see http://www.oasis-open.org/docbook/specs/cd-docbook-docbook-4.3.pdf.

You might discuss the options with the person in charge, i.e. whether a Docbook customization or even an update was possible. If you really must stick to Docbook 4.2, you could still extract all xref format settings from a MIF file before the roundtrip and restore them afterwards (which would require some automated text processing outside FM).

You might retain the cross-reference style by using the "role" attribute. See e.g. the discussion here: http://markmail.org/message/zprsja6ic6bwf3da

[Guest]

I don't follow you exactly. Based on what I think you're asking, you can use xslt templates to process the xml files and change the xref format. In one transformation I have a parameter table of formats eg <xsl:param name="fm1" select="'<exact format name here>'"/> (with fm1, fm2,... to the number of formats), and then in a template, I use xpath to traverse the xml document to find the node type for the target element, get the node name() and I use  <xsl:choose> to assign a format based on the node name. Whatever context you need to discover, you can usually figure out an algorithm to find the context using xslt. For instance, the context of a <Title> element depends on its parent, so I get the the parent node name when the cross reference targets a <Title>. I happen to be doing this on fm 7.x, but stands to reason that fm8&9 should be similar--xml is xml. The cross reference elements look something like this <CrossReference XRefID="xrefid" Format="fmformat" srcfile="filename.fm#xrefid">. After running the xslt transformations, the Format attribute shows format inserted by the xslt based on the context of the target element.

[Lynne A. Price]

Looking at the replies on this thread, there seems to be some confusion between the name and the definition of a cross-reference format. FrameMaker can export the name of the format used by an xref to XML, storing this information in an attribute of the xref element. When it creates an xref during XML import, it uses the format named in the appropriate attribute as the xref format. If the format is defined in the import template, the expected result is obtained; otherwise the displayed cross-reference text indicates the format needs to be defined.

Unmodified, FrameMaker cannot generate or interpret an attribute value as the definition of a cross-reference format. XSLT cannot be used to store xref format definitions because FrameMaker does not expect this information to be in XML; on export, it does not write the information anywhere, on import, it does not interpret anything in the XML document as a format defintion.

An FDK client (FrameMaker plug-in) can, however, preserve this information on round-trip.

     --Lynne

[Guest]

Hi Lynne, Thanks. No confusion for my part about template format definition vs name in the XML/EDD format attribute, although apparently my wording indicated otherwise. The question was a tad convoluted, so I wasn't sure what was being asked. My point was that one can use XSLT to find the context of an xref target (an element name), then use the element name to find the appropriate format (a format name) in a lookup table (implemented by <xsl:choose>) that associates element names or some other criteria with template formats. The lookup table contains the format names from the template and doesn't create anything new--just grabs the appropriate template name based on the context of an element and assigns it to a format attribute in the output xml. The context can be the target element, a parent element, or some criteria defined by a logical algorithm implemented in the xslt. The format definition is in the template.  I gave the best shot as far as I could understand the question. If the ELKEV doesn't feel the question was answered, perhaps s/he could rephrase the question in one or two simple complete English sentences, and we'll cheerfully give it another shot.

--John

[Guest]

However, I just reread the question after another cup of stong coffee, and Michael MH-xpkkLQ may have nailed it.