[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

RE: Discarding generated files in XML (was FrameMaker Release 7.2)

Steve,
I just did a quick FM 7.2 test in Windows. I created a FrameMaker book with the structure:

(book)
   |--(TOC)
   |    |----(BOOK-COMPONENT) ... testTOC.fm
   |
   |--(chapter) ... chapter.fm

where testTOC.fm is a generated table of contents.

I also created 4 variations of the following rules:

writer do not output book processing instructions;
element "toc" writer drop content;
/* fm element "toc" drop; */

and used them to save the book as XML. The variations involved all combinations of:

a) including or omitting "do not" in the output book processing instructions rule (omitting it is the default)

b) commenting out one or the other of the last two rules

The result was what I expected in all cases: with the drop content rule, an empty <toc> element was exported; with the drop rule, no <toc> element was exported.

If you are getting different results but are seeing several other errors, the most obvious things to check are:

1) Make sure you are using the right XML application
2) Make sure you are using the right r/w rules
3) Make sure your rules file has only one rule for each of the generated-file elements (when multiple rules apply to one element, FrameMaker uses the first one to appear in the rules)
4) Debug any other problems
5) Create a small, simple application; get it to work and then pare down the original a little bit at a time (or expand the small one) until you isolate the problem.

I disagree strongly with your characterization of exporting generated files by default as a bug. Some people want the generated information exported. Since it really is simple to suppress it, it doesn't make too much difference what the default is. However, it makes sense that the default should be not to discard information, especially since the default behavior for other elements is not to discard information.
--Lynne




At 03:39 PM 10/21/2005, Steve Whitlatch wrote:
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


Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application development, and training
lprice@xxxxxxxxxxxx http://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284 



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