Type mismatch for the element FrameMaker element (graphic)

If I were to treat them as an unstructured FM file, that would mean manually importing the graphics by reference, and according to your EDD, that's exactly what you are doing; I am not going to import each of these files manually, otherwise, why am I bothering using Structured FrameMaker with an EDD at all

In MY case, I create the structured FrameMaker file within FrameMaker, which of course requires importing the graphics by reference; the EDD is simply telling FrameMaker to open the appropriate dialog box when I insert my Graphic element.

THEN I export the fm file to XML, which stores the path name of each referenced graphics file; FrameMaker does this because of my read/write rules. Then when I read the XML file into FrameMaker, the same read/write rules tell FrameMaker where each graphic file is located; FrameMaker inserts the files by reference WITHOUT my intervention. The EDD does nothing during this process; the "Insert graphic file" in the EDD is used only when I first insert the file by reference within FrameMaker, NOT when the XML file is opened by FrameMaker.

By the way, when FrameMaker exports the fm file to XML, it also writes several default attributes to the Graphic element. These attributes describe the sizing and location of the graphic within the anchored frame. They are not specified in the EDD, though I supposed one could. It is for this reason that I mentioned in the original post that one should not manipulate (size, position, and import) graphics by simply assigning values to attributes...when working within FrameMaker.

BUT it appears you are doing something different. You are starting with an XML file that was created outside FrameMaker and all the graphic files are referenced as entities within the XML file itself. Is this correct? If so, I have to admit that I have never worked with entities, but the structured applications guide (for Frame 9) states:

Importing graphic entities

If the graphic element in markup uses the entity attribute to identify the graphic file, then the

actual graphic file must be identified in an entity declaration. FrameMaker will read the markup,

importing the graphic file by reference into an anchored frame. If the entity declaration is not in

the main DTD, then it should be in the document’s internal DTD subset. In that case, FrameMaker

saves information about the entity declaration on the Entity Declarations reference page of the

resulting document.

The software saves the entity name with the imported graphic inset. The software uses the entity

name, plus the information on the Entity Declarations reference page, to recreate entity

declarations when exporting to markup. For graphic entities the software can use the same

graphic file for import and export under most circumstances. For information about exporting

entity declarations, see “Exporting entity declarations” on page 374. For information about when

the software does and does not use the same graphic file, see “Creating graphic files on export”

on page 374.

I hope that others more familiar with entities will be able to help you. There ARE some read/write rules for entities; maybe you need them also. You may need an entity attribute in your graphic element, but this is just a guess.

By the way... I create an XML file by a third-party application (parts data), which I then open within FrameMaker, applying an XSLT during the process. The XSLT creates Graphic elements with file attributes that specify the locations of the graphics files. This works well. No entities involved. If you have any control over the creation of the original XML file, maybe you can try an approach that does not make use of entities.

Van