Conference vaxuum::document_ft

    The <front_matter> tag is not valid inside a profile. Try
    taking it out and processing the profile again. You can
    leave the <contents_file> tag in the profile; <contents_file>
    is enabled either in a profile or in the front matter.
    
    One point that confuses me: what is the name of your profile?
    You show that you process "caa$rep.profile"...is that a typo?
     The profile is an SDML file, right?
    
    And, why are you bothering to use a profile at all, if you
    are only processing one single chapter? If it is to separate
    the front matter from the chapter, you need to have an additional
    .SDML file that contains the front matter material,
    and then include that front matter file in the profile with
    a second <element> tag, such as <element>(front_matter.sdml).
    
    Hope I'm on the right track with my suggestions.
    -Barbara

    DOCUMENT will create a separate file for each element of a book,
    and will tell TeX to include each one.  Unfortunately, your choice
    of names for the profile and the element caused DOCUMENT to
    create a CAA$REP.TEX file for the chapter and a CAA$REP.TEX file
    for the profile itself.  One of those files says to "\input"
    the other file.  When TeX goes off to "\input" that file it
    inputs the file that it is already reading.  It is in a closed loop
    that goes down six openings (of the same file) and then dies
    with too many input files open.
                            
    Rename your profile to caa$rep_profile.sdml, or something like
    that and try it again.
    
    I would echo Barbara's comments.  Why bother with a profile at all?
    
    bill
    

    Thank you very much for your quick response. Your suggestions worked
    just fine. I renamed the profile file (which is an SDML file regardless
    of the file type '.profile' and got what I expected.
    
    I was not aware that <front_matter> is not allowed in the profile,
    but <contents_file> is (I thought the latter is only valid within
    a <front_matter> context). However, it works with as well as without
    the <front_matter> tag in the profile.
    
    Why take a profile for a single chapter ?  You won't believe it
    but our use of DOCUMENT has progressed so far as to generate SDML
    files with the CAA document generator. (CAA is an internal software
    development tool). The result is a single chapter which can be
    included e.g. in a functional specification. To see how the contents
    part would look like for different flavours of the (query language
    driven) generated SDML file, I created a profile so I didn't need to edit
    the generated SDML file each time to include the <contents_file>
    tag.
    
    My obvious fault was to use the same file name for the profile file
    and the chapter file. Is it documented somewhere that a different
    file *type* is not sufficient for DOCUMENT to keep the files apart?
    
    Anyway, thanks a lot -
    Hans.

    No, we do not make a point of saying that the individual files
    that go into a book should differ in the filename portion of
    their filespecs.  
    
    I suppose it would be reasonable for someone to name the chapters
    of their book BOOK.1, BOOK.2, BOOK.3, etc, and the profile
    BOOK.PROFILE.
    
    We would generate a BOOK.TEX file for the profile and a BOOK.TEX
    file for each of the chapters!    
    
    Hmmmm.  Back to the drawing boards...
    
    bill

>    Is it documented somewhere that a different
>    file *type* is not sufficient for DOCUMENT to keep the files apart?

    No, I believe that it's not specifically documented like that. The
    User Manual shows several examples of how to create profiles, and
    mentions that you should name the profile with any name that indicates
    it is a profile (with an .SDML extension).  Now that you've pointed
    out the oversite, it's obvious that we need to add a big note that
    the profile needs a separate name from the source file(s). I'll
    make sure to add it for next time. Thanks for pointing it out; 
    other users might get tripped up by that problem too. 
    
    -Barbara
    
    

    BTW, meantime I discovered that I only need the /CONTENTS qualifier
    to get the contents printed - the only difference is that they are
    printed after the 'meat' if I don't specify the <contens_file> tag
    either in front matter or profile. As I only want to check the results,
    this works fine for me.
    
    I apparently was somewhat puzzled concerning the relationship of
    the qualifier and the tag - the other day I found that the
    <contents_file> tag wouldn't work properly without the qualifier,
    so I was pretty sure it wouldn't also work with the qualifier used
    but the tag not...
    
    Would it be possible for DOCUMENT in a future release to assume
    the presence of the /CONTENTS qualifier if it finds the <contents_file>
    tag ? (And maybe print an informational message stating so instead
    of telling the user that some old contents file - if present - will
    be used ?)
    
    Anyway, thanks for your support,
    Hans.

Re: < Note 847.6 by UNTADA::CAAHANS "Hans Bachner, ADG Munich" >

>    to get the contents printed - the only difference is that they are
>    printed after the 'meat' if I don't specify the <contens_file> tag
         
         The contents is printed after the 'meat' since the meat
         is in a different file from the contents file, if you
         want your contents in a specific place use the
         <contents_file> tag in your source, and put it where you
         want your table of contents.
             
>    I apparently was somewhat puzzled concerning the relationship of
>    the qualifier and the tag - the other day I found that the
>    <contents_file> tag wouldn't work properly without the qualifier,
>    so I was pretty sure it wouldn't also work with the qualifier used
>    but the tag not...
         
         It does work properly, you just get some extra messages
         which tell you that you have a <contents_file> tag but
         didn't specify /CONTENTS.   And since you didn't run with
         /CONTENTS document didn't make an index, as you requested
         from the command line.  Get an up to date V1.0 User manual
         and read up on the relationship between /CONTENTS and
         the <contents_file> tag.  I think you will understand.
             
>    Would it be possible for DOCUMENT in a future release to assume
>    the presence of the /CONTENTS qualifier if it finds the <contents_file>
>    tag ? (And maybe print an informational message stating so instead
>    of telling the user that some old contents file - if present - will
>    be used ?)
         
         This would be an unacceptable behaviour, if you didn't
         /CONTENTS on the command line it means you don't want
         a contents file generated, nor printed.  And you especially
         don't want a contents file from a past version, after
         all it very well might be out of date and including that
         file would be WRONG.
         
         This problems has been long thought out, and we believe
         we have come to an acceptable solution.
         
         Besides, this problem belongs in a new note.
         
         Chris