Graphic elements in XML

[Gorly]

Guys, I guess I'm kinda stupid or blind or both, but I got this trivial issue:

I try to roundtrip graphics from a simple EDD to XML and back.

So I got this pretty simple rules in EDD, DTD and RWR:

EDD:

element (graphic): image

   attribute list

      1. Name: href          String          Optional

   Initial graphic element format

     1. In all contexts

           Insert anchored frame

DTD:

<!ELEMENT image       EMPTY>

<!ATTLIST image      href       CDATA       #IMPLIED>

RWR:

element "image"

{

          is fm graphic element;

          attribute "href" is fm property file;

}

I got a basic element as top level element defined to get the image placed...

So, what bothers me is, how the hell do I get the damn href attribute told, where the image reference is? The XML output places the image element without problems - but the ref is missing.

Pulling my hairs out on this one...

Cheers Alex

[Gorly]

Now this is rediculous, I just tried to save the RWR as FM document and out of a sudden the whole thing works...

What the hell?!?

Anyone able to explain me THAT? (strange enough, the href attribute is populated in source code and no more in FM view)

[Van Kurtz]

Alex,

First, a read/write file is always an fm file. I do not believe it can be a text file, but not sure.

Second, your EDD and read/write files are the same as mine, except that I do not include the href attribute in the EDD, that is the FM structure. I am not sure that it is necessary, because FrameMaker stores that information internally. Its use in the XML is to provide a place for FrameMaker to store that for roundtripping. There are a bunch of other attributes that you can add to store information about the scaling and placement of the image; those attributes are also not required in the EDD but needed in the XML. Maybe this is why FrameMaker is not storing the href in the href attribute in the fm file.

Van

[Gorly]

The RWR can be stored in a txt file, too. Strange thing is, it didn't work at first, but when I changed to a FM file and lateron back to a txt file, it still worked (I better don't ask why). We worked with txt files all the time.

I know that most attributes of the gaphics element are stored internally, but I like to keep the attributes in the EDD and DTD consistant, if only to remember myself of what is going where.

What I found out after some testing is, that the ditafm_app and the standard api client seem to work completely different on that issue. While in FM9 this translation worked, in FM11, the behavior is completly different. The ditafm_app doesn't translate the notation, while the default API client does.

-Alex

[Van Kurtz]

Alex,

I do not use DITA, but I hear from this forum that its implementation in FM11 is different from earlier versions.

I vaguely recall a thread on this forum in which the user tried to change the location of a graphic by editing its URL displayed in the attributes pod. One cannot do that. One must use the standard FrameMaker tools to insert graphics, even in a structured document. So, if you do display the file location as an attribute, maybe you should make it read-only.

Van

[Gorly]

Van,

we're not trying to manipulate the location of things by changing the attributes manually. I simply had the problem, that on saving the file, the file location wasn't populated into the attribute at all (even if the RWR told FM to do so). Seemingly the ditafm_app uses some other processing of XML than the default api client.

This circumstance produces loads of land mines I have to defuse, before I can let our documentation cross the terrain (since the first document I sent on the journey exploded right into my face).