Save as XML not using specified XSLT transform

[richardlight]

I am trying to develop a FrameMaker application for simple TEI documents. When I try to round-trip by saving my FrameMaker document back out as XML, the XSLT transform I have specified has no effect. If I delete that transform from the Structured Application Designer advanced settings, I get exactly the same (incorrect) result.

[richardlight]

Apologies: the error occurs earlier in the process and doesn't give the XSLT transform a chance to run. The issue is that attributes of table elements (rows, cells) which are mentioned in the application's rules file are 'doubling up', making the initial XML invalid. I suspect that this happens to attributes which are present in the data but are not mentioned in the rule for that element. Arguably, this is a bug.

[Ian Proudfoot]

I moved this thread to the FrameMaker Structured community as the question is specific to structured FrameMaker.

The default behaviour is for FrameMaker to prevent the XSLT from being applied if the XML is invalid.  However this can be a silent failure and it is possible to miss the error. If the XML is not well-formed the XSLT processor will stop the transformation with plenty of error messages. However let's get back to your problem...

There are some long-standing cases of strange behaviour when trying to override FrameMaker's built-in read/write rules for tables. Could you explain what you are attempting and we can try to resolve the problem.

Ian

[richardlight]

Cracked it, I think. The DTD declared a number of attributes for 'table' elements with fixed values, e.g.:

<!ATTLIST cell

  ...

    role CDATA "data"

    rows NMTOKEN "1"

    cols NMTOKEN "1"

    TEIform CDATA "cell" >

These attributes were output once when the document is read into FM (via an initial XSLT transform, which instantiated all the fixed attributes in the DTD), and I guess they were output a second time when it was saved. As I said, this feels like a FM bug to me.

I got round it by re-declaring all these attributes as having an #IMPLIED default value - I don't use them anyway. It now round-trips the XML, with only a handful of required attribute values missing to spoil the validity of the saved result. I hope that I can sort those out in a similar way, by adjusting the DTD.

Incidentally, in the Structured Application Designer, putting a value into the EDD box doesn't seem to 'stick'. Save it, and when you re-display the dialogue the EDD value has gone. This means that I have fiddle around, loading the EDD and then doing File - Import - Element definitions to get my custom styling for each document.

[richardlight]

Ian, the element which has lost its attributes is <index>. I guess this is another 'special' element for FM? Is there a document I can refer to which would save me having to guess and cast around on the Web for information on the custom elements in FM and their properties/attributes?

Thanks,

Richard

[Ian Proudfoot · Accepted solution]

Richard,

Have you seen the Structure Application Developer's guide and reference? These are the definitive documents on the subject. You can find them on the FrameMaker Developer Center.

Ian

[richardlight]

Ian,

That's spot on: thank you. Hopefully no more questions ...

Richard

[richardlight]

Thanks for the help. Just to say that I have now managed to round-trip a TEI document (TEI Lite, P4) into FrameMaker and out again, with reasonable display of the contents in FM and the option of using it to generate a plausible PDF. The two native FM features I needed to tackle were tables and cross-references. If anyone in this community is wanting to do anything with FM and TEI, I would be happy to share what I have learned.

Richard