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

[Steve Whitlatch <swhitlat@xxxxxxxxxx>]

On Friday 21 October 2005 07:46 pm, Lynne A. Price wrote:
> Steve,
>    I just did a quick FM 7.2 test in Windows. I created a FrameMaker book
> with the structure:

OK, Lynne, well thanks. I'll try again when I get a chance to use FrameMaker 
7.2. The behavior I describe is with version 7.1, and also with 7.0. However, 
that may be irrelevant. Thanks for the debugging suggestions. I'll try them. 

Steve Whitlatch    

>
> (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.   **