Skip to main content
R
richardlight
Known Participant
April 16, 2019
Answered

Save as XML not using specified XSLT transform

  • April 16, 2019
  • 1 reply
  • 1565 views

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.

This topic has been closed for replies.
Correct answer Ian Proudfoot

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


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

1 reply

R
richardlightAuthor
Known Participant
April 16, 2019

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
Ian Proudfoot
Legend
April 16, 2019

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

R
richardlightAuthor
Known Participant
April 16, 2019

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.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices