RE: FrameMaker Release 7.2

["Steve Whitlatch" <swhitlat@xxxxxxxxxx>]

[added FrameSGML@xxxxxxxxxxxxxxx]

> At 12:47 PM 9/19/2005, Steve Whitlatch wrote:
> >Also, open question to anyone at all. Given a FrameMaker book, and of 
> >course by "book" I mean that it includes all the usual generated lists 
> >(TOC, LOT, LOF, Index, etc.), how does one prevent FrameMaker from 
> > exporting these generated lists as part of the XML tree?


> In the book, if you haven't done so already, wrap the BOOK-COMPONENT 
> bubble for a generated list in an element such as GeneratedList, TOC, etc.
> If you want to drop these elements completely, add a read/write for each 
> of them in the form:
>        fm element "GeneratedList" drop;
> You can also retain an empty element in XML to indicate the position in the 
> hierarchy where you want a FrameMaker generated file. Use a rule of the form:
>        element "GeneratedList" writer drop content;
> 
>          --Lynne


Thanks Lynne. No joy (yet), of course it is possible that it's somehow my 
fault on account of an as-yet unknown mistake I am making. That would be 
the best-case scenario, I think.

I started by checking the structure view to make certain that all FrameMaker
BOOK-COMPONENT elements (bubbles) are wrapped. They are all listed in the 
structure view as child elements of "toc", "lot", or "index" elements. So, 
they are "wrapped."

I tried following read/write rules:

   fm element "toc" drop;
   fm element "lot" drop;
   fm element "index" drop;

and I tried the following:

   element "toc"
    {
      is fm element "toc";
      reader drop content;
      writer drop content;
    }

   element "lot"
    {
      is fm element "lot";
      reader drop content;
      writer drop content;
    }

   element "index"
    {
      is fm element "index";
      reader drop content;
      writer drop content;
    }

and I tried the following:

   element "toc" writer drop content;
   element "lot" writer drop content;
   element "index" writer drop content;

In each case, I made sure that the read/write rules file was still 
valid by doing a Files > Structured Tools > Check Read/Write Rules.

None of the above read/write rules seem to have any affect whatsoever. 
I say that because when I select File > SaveBookAs > XML,
FrameMaker behaves the same with or without any of the above read/write 
rules. It still exports to the filesystem an ascii-readable file that 
coincides with each FrameMaker-generated list in the book. None of the 
FrameMaker generated lists is part of the imported XML. Each generated list 
is added to a FrameMaker book so that I can use FrameMaker's book-building 
capabilities. Each of the export files coinciding with a FrameMaker generated 
list contains PIs specific to FrameMaker and the plain, untagged character 
data of its respective generated list. 

As usual, upon export, FrameMaker displays the "Save as XML Log," which 
contains several pages of error messages, one error message for each line 
of exported character data for each file coinciding with an exported 
generated list. For example:

   Error at file E:\. . .\f2Arch_bookTOC.e02 line 3 character 1, Message: No
   character data is allowed by content model
   Error at line 5 character 1, Message: No character data is allowed by 
   content model
   .
   .
   .

The "Save as XML Log" goes on like that for four pages until it eventually 
poops out and says "Number of messages has exceeded the maximum. Processing 
of this document or book component will continue without additional 
messages." Then it issues some more error messages and ends with "Parsing 
aborted."

The XML is valid prior to import, and of course the imported XML does not 
contain any of the data that causes the error messages upon export. All of 
that data is generated internally by FrameMaker. The validity errors I can 
see in the "Save as XML Log" are all on account of unwanted export data that 
is not included in the imported XML. It is data that should not be exported 
at all, but rather used only by FrameMaker in its book-building processes.

In my opinion, FrameMaker should by default not export any data from any 
of its generated lists. That it does so is a bad bug. 

Anyone know if this bug is fixed in FrameMaker 7.2? I am using 
FrameMaker 7.1.

Do the above read/write rules work for anybody?

Thanks, 

Steve Whitlatch



** To unsubscribe, send a message to majordomo@xxxxxxxxx **
** with "unsubscribe framers" (no quotes) in the body.   **