Copy link to clipboard
Copied
Hi all,
I have been a framemaker user for years on and off. I want to use the MIL-STD 40051-1C/2C DTD. How do I configure FM 2017 to use the dtd and stylesheets.
I have downloaded all required files from: https://pubsweb.redstone.army.mil/DTD-FOSI/Webpages-60/ALLDTDs-AMCOM.html I can't import or start using them. I don't even know if FM 2017 can use the mil spec style guide anymore. Can somebody help explain how I would go about using the mil spec structure to write technical manuals? I need work packages. PMCS, operator work packages. Please help! I am using the structures already built into framemaker. I am just not happy with the output. I want more of a military style workpage for maintenance procedures. I have used FM with this mil spec before, but somebody else had already configured FM to use mil spec as a template. So I am at a new company and want to produce nice technical manuals. I have searched the web and have found nothing all day, I tried various methods from other users to no avail. Please help.
Thank you!
Wayne Evans.
Copy link to clipboard
Copied
Hi Wayne,
There's good and bad news for you. Yes FrameMaker can be configured to use the MIL-STD 40051-1C/2C DTD. However the supplied stylesheets are in FOSI and XSL-FO formats, neither of which are supported by FrameMaker.
To achieve the required output formatting will require the development of a FrameMaker EDD. I have done this for MIL 40051 in the past so I can confirm that it can be a significant undertaking. FrameMaker provides all of the tools that you need but you may prefer to hire the services of a FrameMaker developer.
The development steps are:
I hope that helps
Ian
Copy link to clipboard
Copied
Ian,
Do you know of any training that would be helpful to take on this task?
Regards,
Jane
Copy link to clipboard
Copied
Tech Comm Tools will be publishing a book you may find helpful.
http://www.techcommtools.com/books/
Regards,
Jeanette
Copy link to clipboard
Copied
Jeanette,
Thank you and nice to hear from you again (I do believe we took one of those courses together). This is a topic not covered in the books. This falls more under a developer and is going to involve the list in Ian's post. There are some basic skills (e.g. developing an EDD and template) that are covered in the mentioned book and I do highly recommend them for that. I am looking at more the Structure Application, read/writer rules, XML round tripping (which is a skill set outside of FrameMaker) and possibly XSLT (also a skill set outside of FrameMaker) training/information.
Jane (one of these days I will get my profile updated to the correct spelling of my name)
Copy link to clipboard
Copied
Mebbe a dumb Q - but don't any of these wizard small consulting firms have a set of 40051 templates / structured app fileset available for sale, license copies, et al?
Obviously large outfits with lots of writers may build/maintain these in-house, but it would seem a no-brainer (and a lucrative small biz consulting enterprise) to provide these for sale or license, no?
Any thoughts or POCs to those that might know?
I don't know about any of you folks working with DoD customers, but seems that virtually every new logistics contract requires XML deliverables for military tech manuals. Which means that for those of us with tons of legacy TMs done in Frame, it time to either do XML in Frame, or migrate to other platforms (XMetal, Oxygen, PTC, etc.) Starting from scratch to home-build the attendant Frame template files / Structured app to do Mil-Std XML TMs in frame and output pretty PDF TMs is not exactly cost effective, n'est pas, mon amis?
So, who's got the list of experts that build/sell/license copies of the rock solid 40051 Frame templates?
Any/all insights greatly appreciated.
Best regards,
Bob W, Bristol RI
Copy link to clipboard
Copied
Bob,
I have done this very thing for a customer in the past, but not for resale unfortunately.
I would consider taking this on and supporting it as a commercial venture. I did the same thing many years ago for the ATA iSpec 2200 specification and ASD S1000D. Both implementations bear many similarities with 40051 and are still commercially available, but though another vendor.
Perhaps we could discuss this offline? Send me a PM if interested.
Best regards
Ian
Copy link to clipboard
Copied
I could sure use some insight to the structured app files for this spec. It seems one can create an EDD from the supplied DTD. I am really struggling with the read write rules file, however.
Primarily, I am trying to get graphics to display.
This is how a graphic is coded in the XML data:
<!ENTITY ja23-0000 SYSTEM "Graphics\ja23-0000.tiff" NDATA TIF>
...
<graphic boardno="ja23-0000"/>
This is the DTD:
<!ELEMENT graphic (mapref*)>
<!ATTLIST graphic
%graphicatt;
hplace (left | right | center | none ) #IMPLIED
graphsty NMTOKEN #IMPLIED
applicable IDREFS #IMPLIED
%bodyatt;
>
EDD created in FM from above DTD, but an Element (Graphic) cannot have a General rule, mapref* (?):
Element (Container): graphic
General rule: mapref*
Attribute list
Name: boardno String Required
Name: boardfile String Optional
Name: reprowid String Optional
Name: reprodep String Optional
Name: unitmeasure Choice Optional
Choices: mm | cm | px | in | pt | pi
Default: in
Name: hscale String Optional
Name: vscale String Optional
Name: scalefit Choice Optional
Choices: yes | no
Name: alt String Optional
Name: hplace Choice Optional
Choices: left | right | center | none
Name: graphsty String Optional
Name: applicable ID References Optional
Name: inschlvl Choice Optional
Choices: 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 |
55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 |
83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99
Default: 0
Name: delchlvl Choice Optional
Choices: 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 |
55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 |
83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99
Default: 0
Name: comment String Optional
Name: changeref ID References Optional
Name: idref ID References Optional
Name: assocfig ID References Optional
Name: skilltrk String Optional
Name: security Choice Optional
Choices: uc | fouo | c | s | ts
I've tried the following in RW rules file:
element "graphic" {
is fm graphic element;
attribute "boardno" {
is fm property entity;
is fm attribute;
}
}
element "graphic" {
is fm graphic element "graphic";
attribute "boardno" is fm property file;
attribute "entityref" {
is fm peroperty entity;
is fm attribute;
}
}
Thanks for any assistance.
Copy link to clipboard
Copied
Wayne,
The first variation of your r/w rule is the one you want. The value of the boardno attribute is the name of the entity that identifies the graphic rather than the pathname of the graphic file.
However, you'll need to use a slightly different structure in FM than in XML. FM requires graphic elements to be empty since the graphic content is in an external file. However, your DTD defines graphic as
<!ELEMENT graphic (mapref*)>
instead of
<!ELEMENT graphic EMPTY>
If your documents don't use the mapref element in this context, there's no problem. Just make sure your EDD defines graphic to be a graphic element. If you do need mapref, you'll need to use a slightly different structure in FM than in XML. The FM version would use one element for the graphic only and another that contains the graphic-only element and the maprefs. For example, you could use the EDD equivalent of either:
<!ELEMENT graphic (image, mapref*)>
<!ELEMENT image EMPTY>
or
<!ELEMENT graphic-wrapper (graphic, mapref*)>
<!ELEMENT graphic EMPTY>
The advantage of the first variation is that you won't have to change references to graphic within existing content models. The advantage of the second is that the boardno attribute is on the graphic element in both FM and XML. In either case, you will need to change between the variant FM model and the DTD model when you move documents in and out of FM. You can do so either with a custom FDK client or with XSLT. If you use XSLT, you'll need to prepare a variation of the DTD that matches the structure you are using in FM.
--Lynne
Copy link to clipboard
Copied
Thank you, Lynne.
I changed the graphic element in my EDD to be a Graphic type without the mapref* rule, and I used my first RW rule version.
The graphic is displayed in FM but it is very large and the boardno attribute is missing <no value>.
Is there a way to set global scaling on the element and correct the attribute value?
Copy link to clipboard
Copied
Brian,
1. Is the boardno attribute declared in the EDD? FM won't set the attribute in FM unless it exists.
2. You can use a subrule of the element rule for a graphic such as:
FM property width value is "4.5in";
to make all occurrences of <graphic> import at the same width.
--Lynne
Copy link to clipboard
Copied
Hi Lynne,
I missed your post and I am sorry about that. Thank you for your help. To your questions:
1. Is the "boardno" attribute simply listed within the graphic element or must it be declared elsewhere? I pasted the EDD definition a couple posts above.
2. Width seems to work to crop the frame size, yet the image is still over sized.
Some background if interested. I had to hire an agency to convert our manuals to the XML structure. That work was completed brute force, but the content has been rejected. The agency cannot perform the required content editing and I will be in trouble for not being able to get this done as it has been extremely costly so far. This is really my first time in structured content, but I've been trying to get a handle on it.
The content I have can be opened in FM and saved as XML, and it appears the XML text is coming out fine, aside from plain text formatting such as line breaks and element indentation. So far I only note the missing boardno attribute, but there is so much I don't know and I'm sure to be taking tables and xrefs for granted. I only need to deliver XML and graphics files.
Thank you,
Brian
Copy link to clipboard
Copied
Brian,
In a typical XML project in FrameMaker, most elements and attributes in one representation correspond to an element or attribute with the same name in the other. However, there can be exceptions. For example, some names can be different in the two views (for instance, the XML names may be abbreviations whereas the FrameMaker names may be more complete or the FrameMaker names may use words common to the end users' vocabulary even when different terms are used in XML). There may also be elements and attributes that are needed in one representation but not the other. Such differences can often be specified in r/w rules.
One common type of difference between the XML and FM models involves XML attributes that correspond to FrameMaker properties and therefore do not need to be included in the structure in FrameMaker. Consider, for example, the number of columns in a table. XML documents often use an attribute to indicate this quantity. Your DTD probably has an element named tgroup with a cols attribute, where tgroup is a table in FrameMaker and cols defines how many columns there are in the table. There is no need to retain the cols attribute in FM even though it is required in XML. The number of columns is an inherent part of FrameMaker's table structure; when you open an XML document, FrameMaker creates a table with the specified number of columns. You can then edit the document, including adding and removing columns from a particular table; when you save the result as XML, FrameMaker sets the value of the column attribute to the number of columns the table has at that time.
When you open an XML document, through read/write rules, an attribute can be treated in the following ways:
When you save a document as XML, an attribute can be set from:
Other possibilities are supported with XSLT or the FDK.
The read/write rule:
attribute "boardno" {
is fm property entity;
is fm attribute;
}
tells FrameMaker that the value of the XML boardno attribute names an entity whose definition has an external identifier for a graphic file to be displayed. When you import an XML document, FrameMaker creates an anchored frame from the named entity. It does not store the attribute value as an attribute in the resulting FrameMaker element. However, it does save enough information about the entity declaration to recreate the entity declaration should you save the document as XML after editing. The saved information is stored on a reference page (Entity Declarations) rather than in the element structure.
If you omit the "is fm attribute" subrule, then when you open the DTD to create a new EDD, FrameMaker does not even create a boardno attribute in the EDD. Suppose you have opened an XML document that declared 20 graphic entities and during editing you add 5 more images. When you save the document as XML, FrameMaker writes out the 20 original entity declarations and adds 5 more. The new ones must include entity names for the new images and FrameMaker gives them names such as Graphic1, Graphic2 and so forth; you can change the "Graphic" prefix with a read/write rule.
Suppose, however, you want the entities to have meaningful names such as a database key or a keyword or phrase that describes the graphic. In this case, you can include the "is fm attribute" subrule. When it exports a new graphic for which the attribute value is set, FrameMaker generates an entity declaration that uses the attribute value as the entity name. When it exports a new graphic that does not provide a value for this attribute, FrameMaker still uses the sequence-number based named (Graphic1, etc.)
Note that entity names must start with a letter and contain only letters, digits, hyphens, underscores, and periods. In particular spaces between words are prohibited.
This long introduction leads up to the fact that boardno must be required in XML and, if you plan to open existing XML documents that contain graphics, it must be optional because FM does not retain any existing attribute values.
--Lynne
Copy link to clipboard
Copied
Brian,
You mention that "it appears the XML text is coming out fine, aside from plain text formatting such as line breaks and element indentation". Line breaks and indentation are probably not significant. If you are losing significant white space in the original import of XML to FrameMaker, you can try turning off RemoveExtraWhiteSpacesOnXMLImport in maker.ini.
If you want to preserve XML line breaks within a paragraph in FrameMaker, you can try the r/w rule:
reader line break is forced return;
If you are getting too many line breaks within a paragraph when you save FrameMaker documents as XML, you can try the rule:
writer line break is n characters;
where n is a large number.
--Lynne
Copy link to clipboard
Copied
Brian,
You say that "Width seems to work to crop the frame size, yet the image is still over sized."
When FrameMaker imports a graphic, it creates an anchored frame, and places the graphic image inside it. There are 5 properties that can be set either in read/write rules or in attributes to control the size of the anchored frame, size of the image, and placement of the image within the frame:
1. Height and width are the height and width of the frame. Default attribute names are "height" and "width" but read/write rules can change the attribute names.
2. Import size (default attribute name "impsize") is a pair of dimensions separate by a space. For example, setting the attribute to "5.5in 3in" imports the image with a height of 5.5 inches and a width of 3 inches.
3. Horizontal offset and vertical offset, with default attribute names "xoffset" and "yoffset" specify the width of margins to leave in the anchored frame at the left side of image and at the top of the image. If height and width are not specified, the same margins are used on the right side and bottom. (The default for both properties is 18 points.)
Use read/write rules for properties you want to set to the same value for all graphics in your documents; use attributes if you have the information to set them. If the values differ from graphic to graphic and you don't know what these property values should be, you might need to edit the imported document to get the look you want.
Here's a possible scenario that may or may not resemble what you have. Suppose someone is importing XML files in which there is a height attribute and a width attribute. The design of the XML markup does not account for FrameMaker's model in which there is an image inside a frame. Thus, the intent of the original markup is that the frame and image have the same height and width and there are no offsets.
Dealing with such data, I would use XSLT (which FrameMaker can run automatically as a pre-process when opening an XML document) to add an impsize attribute, setting it to the value of height, a space, and then the value of width. I would use read/write rules to set the offset to 0. A variation DTD then defines the new impsize attribute would be necessary.
--Lynne
P. S. This thread is getting long. If you have further questions, please start new discussions for them.
Copy link to clipboard
Copied
Thank you, Lynne. I set the boardno attribute as optional and that seems to work. I have a lot to digest there and read from the developer's guide.
Brian