40051C dtd graphics vs fm

[keh1]

There is a known issue between framemaker and the army 40051C dtd whereas fm graphic element is empty but the 40051C dtd graphics element is a container with mapref*. Result is that the xml file you build will not validate because it shows as undefined.  Is there a rwr or application rule that will get around this problem?

[Ian Proudfoot]

Elements are assigned a type that maps to a FrameMaker object type. A container element can include child elements but a Graphic element cannot contain any child elements, so we have to work around that limitation. If we look at a similar case from the S1000D specification, the graphic element can contain one or more hotspot elements. That means you have to have a different structure in the FrameMaker EDD compared to the source XML's DTD or Schema. 

In this example I have created a new fm.graphic element that is a container for the real graphic but also allows hotspot elements too.

The last part of the puzzle is to create a transformation that maps from the source structure to the EDD structure on import and another that does the reverse transformation on export. FrameMaker has two ways to do this:

• XSLT transformation which you can set up as a feature in the XML application for 400051C.
  or,
• Write a transformation client using the Structure API (quite difficult).

I hope that helps?

Ian

[keh1]

Thanks for your quick response and appreciate your advice.  Long time unstructured user but only a few months structured experience, learning by manuals and forums.  I added your suggestion to my EDD and it validates but it will not save as a dtd, "graphic allready declared".  I used a work around similar to one previously posted on a past forum.  I added a Graphic Element for "anchframe" and added "anchframe" to the existing Graphics Element "anchframe, mapref*" to my EDD.  I saved out as a dtd and updated the definitions in my working file and template and am able to create my xml file.  I guess this is an OK short term fix but I assume my xml will be parsed against the 40051C dtd and it's not going to work. I assume this is where the XLST transformation files come into play. Are the transformation files applied to the xml file upon export from framemaker and become part of the xml file and are seen by the 40051C when it parses or are they just applied to the file and thats it? If I have to go this route, how would I get a XLST transformation file created?  Thanks again for your help.  Hope I am not being to cryptic.

[keh1]

Is framemaker the best tool to use for updating the MIL-STRD-40051 dtd or is it better to use arbortext? Has anyone sucessfully delivered using framemaker to develop the xml files?  If so, other than the graphics issue, what other hurdles have to be overcome to develop the files?

[Ian Proudfoot]

A lot of questions to answer here, but I'll try to help.

There are several parts that may be needed for a successful XML application.

1. The primary DTD or XML schema that defines the permitted structure for the XML file.
2. An optional import XSLT file that can be used to tranform the structure of the source file into a structure that is compatible with FrameMaker's structured object types. Will be accompanied by a secondary DTD that matches the result of the XSLT transformation.
3. Read/Write rules that are used to identify the type of FM object that will be defined in the EDD.
4. An EDD where the structure of the FrameMaker document is defined along with all context-based formatting rules. This can be generated from the Primary DTD when no XSLT is used, or the Secondary DTD.
5. An optional export XSLT file to transform the FrameMaker structure back to the structure that matches the source DTD.

That probably sounds far too complex, but it's fine once you're used to the concepts. It also helped by the very useful Structure Application Designer which includes a tool for building the Read/Write rules.

This whole process is documented in the Structure Application Developer Guide and Reference: FrameMaker developer centre

Writing XSLT is a separate skill, and while it's not difficult to get started, there are several complexities that will catch you out. 

You may ask is it worth the effort and my answer is yes if you need all that FrameMaker can give you. There's nothing better if you need to publish directly from the ready-formatted FM documents. If, on the other hand, you only need to deliver XML and graphics there are easier ways to acheive your aim. When I'm not developing FrameMaker applications I work with various XML technologies including XSLT, and for that I use Oxygen Editor which can also be used as an excelent document editor.