Skip to main content
Participating Frequently
May 15, 2013
Answered

Read/Write Rules: Generic Identifiers & FM Tags

  • May 15, 2013
  • 1 reply
  • 1858 views

I have seen this question answered in one of the dev guides but I cannot find it again.

My question is whether it is legal within the read/write rules to refer various generic identifiers to the same FM tag/element.

For instance:

element "body" is fm element "Paragraph";

element "preface" is fm element "Paragraph";

Thanks!

[moved to FM Structured forum]

This topic has been closed for replies.
Correct answer Van Kurtz

Van,

This is more of a general fm question, but what if there is no pre-existing XML file. Do I need to create one? I have an unstructured fm document that I am converting to structured. Do I create an XML file from that?

Does every structured fm document need a prior XML document?

Thanks!


Does every structured fm document need a prior XML document?

No. It depends upon the application. In my case, I create user manuals using structured FrameMaker. Our writing team created an EDD that does what we want and need it to do. We do not export or save the structured FrameMaker files as XML; however, we could if the need arose, for example, to create HTML versions for viewing in a browser. This application works for our needs.

I have one application in which I begin with XML. When I create a parts catalog, the part information is exported from a database as XML. The structure of this XML file is determined by the database; it does not match the structure design in my EDD. But I use an XSL transform to convert the parts XML into a structure that is valid with respect to my EDD. Again, it depends upon your application.

Some people DO export their structured FrameMaker files to XML. They may want to do something else with the content that requires its being in XML. Or they may use the XML for storage because XML files are smaller than FrameMaker files. Then when they open the XML files in FrameMaker, they are imported into a clean template, which cleans out any overrides and any junk that may have acummulated in the FrameMaker files.

If your goal is to convert unstructured FrameMaker files into structured files, then I suggest concentrating on developing the EDD that works for your needs. Export to XML can come later if you need it.

Van

1 reply

Van Kurtz
Inspiring
May 15, 2013

I do not know the definitive answer, but it would seem to work when writing, because two elements are being mapped to the same element. 

When reading, however, it would be ambiguous. because the rules would not know which element to map the Paragraph element to. The ambiguity would be broken if FrameMaker ignored all assignments after the first, for example.

Have you tried it?

Van

abobuAuthor
Participating Frequently
May 15, 2013

Thank you for your input. I have not tried it yet. In fact, this is my first time using FrameMaker - the company I work for wants me to create the DTD, EDD, read/write rules, etc.

I guess my larger question is how (and where) are personalized tags/elements translated so that framemaker understands what they are. I currently have all of the stylistic components written in the EDD, but the translation from generic identifier to fm, so that FrameMaker can understand it, is still troubling for me. I am still going through all of the guides and manuals but it is quite all over the place.

Inspiring
May 15, 2013
First, yes, r/w rules can define many-to-one and one-to-many mappings. As Van as observed, such mappings are unambiguous in one direction and ambiguous in the other. In the specific case you mention of two XML element types mapped to the same FrameMaker element type, opening XML content in FM is clear; creating XML content is ambiguous.
The convention is that the first encountered rule is used in ambiguous situations. Hence, with the original example, FM Paragraph elements would always map to XML body elements, never to XML preface elements. If you want some FM Paragraph elements to be saved to XML as body elements and others as preface elements, you'll need a custom API client to distinguish them.
The "first rule has priority" convention works except in the mapping of special characters to entity references, where which rule is used seems to be unpredictable.
Second, if you are responsible for designing both the EDD and the DTD, why are using different element names in FrameMaker and XML? Is there a reason not to use the same names in both representations of the document content?