I am building in a FM 12 structured app for the Army's MIL-STD-2361 XML. The <xref> cross-reference element has multiple IDREF attributes, each specific to its associated element. For example @figid is for <figure>.
If this is a read/write rules issue, I can't figure out what it is. I get an error if more than one property cross-reference id is used.
FM does not support this model directly, but you can probably use simple XSLT transformations to go back and forth between a variant model used in FM and the one defined in the DTD.
In particular, a FM cross-reference element can have any number of attributes, including multiple IDREF or IDREFS attributes. The text displayed for the cross-reference element is determined by the element identified by the first such attribute declared in the EDD. If the attribute is declared IDREFS, FM uses the first value in the attribute to determine the displayed text. In your case, thus, FM will always use the value of tasked. A second attribute can be used to specify the cross-reference format to be used in FM. These conventions select at least two possible variations that could be used in FM:
Instead of a single xref element, define multiple cross-reference elements such as taskxref, figurexref, and so forth. These various elements could all have an IDREF attribute with a generic name such as id, or could have the appropriate name from the attributes defined in XML. In either case, you can use read/write rules to rename the element (and the IDREF attribute, if necessary) when you save a FM document as XML. When you open an XML document in FM, use an XSLT preprocess that finds the referenced element and determines its type (element name) to determine the element tag to be used in FM.
An alternative is to use the xref element tag in both XML and FM, with a generic IDREF attribute used in all cases. In addition, define a new attribute for use only in temporary XML files that specifies the name of the FM cross-reference format used or to be used. When saving an FM document as XML, use an XSLT postprocess. FM will therefore write a temporary XML file that is the input to the postprocess. With appropriate r/w rules, the temporary file will contain both IDREF and format attributes. The postprocess will determine the name of the IDREF attribute and possibly the values of one or more of the CDATA attributes from these attributes. To open an XML document, use an XSLT preprocess to create a temporary file that sets IDREF and format attributes.
The catch here and the reason for ("probably") in the opening paragraph above, is that the XSLT coding is simple if you know what cross-reference formats will be used. If you want a more flexible tool that is not based on knowledge of the formats used in FM, then you will probably need to use the FDK as Scott Prentice suggested on another list.