Conference vaxuum::document_ft

    See topic 156.0 and the replies to it.
    
    Let me know if that doesn't solve the problem.

Have read Note 156.0, and Section 7.2 of the User's Guide, Part I, on
cross-reference files.  Have the following questions/observations.

1.  The User's Guide and the Note seem to assume that you will 
    normally do a book build before doing an element build.  This
    may be true for revisions, but not for new books.  I would
    like the capability to specify the chapter number in an
    element build.  I realize the advantages in modular documentation
    of not being locked in to a specific chapter, but would be nice
    to have cake and eat it, too.  Perhaps a qualifier on DOCUMENT
    command, rather than a tag in the element?

2.  In my case, I was doing an element build after a book build,
    but the revision included doing some new section references.
    I think that is what blew up the element build, and produced the
    error message; DOCUMENT couldn't find the new references in the
    .CRF file.  All the new section references were within the
    chapter, so why couldn't DOCUMENT update the .CRF file?
    Even if the new references were in another element, I would
    prefer that DOCUMENT just print out the logical name, 
    rather than blowing up the build.

3.  Your comment in note 156.0, about DOCUMENT creating a new
    CRF file, which may be in error because of a crash or
    CTRL/Y, seems dangerous to me.  Why can't DOCUMENT create
    a temporary file, and then write the .CRF at the end, after
    it is sure the build is successful?  Telling users that
    they may have to delete the latest version, seems a bit
    harsh.

4.  The User's Guide states that the .CRF file is not readable.
    It seems to be a text file; at least when I TYPEd it, it
    had entries I could read.  Why scare them off?

    Re. -1
    
    Number 3 of the previous message is an excellent idea!  I vote for
    having a temporary CRF file that is saved only if the tag translation
    of the book build is successful (it shouldn't be dependent upon
    successful completion of the entire book build).  If the tag
    translation is successful, you should be able to produce a useable CRF
    file even if TeX or the Device Converter bombs. Correct? 
        
    This would save a lot of new users from getting the confusing "CRF file
    incomplete" message if they used CTRL/Y to kill the job (or if it
    aborts for other reasons).  And it would save experienced users from
    themselves when they accidentally enter PURGE before deleting the
    newest version of the CRF file. 
    
    	-hkc

    
    re: .2 item 1
    
    we have added tags that allow users to specify chapter numbers and
    appendix letters, but they work only in the context of a 'file build',
    that is, only if there is no profile involved.
    
    patti anklam

    re: .2 items 2 and 3
    
    For sure, it is poor programming to produce a partial file and
    then refuse to do the next command because the last one did not
    produce a correct file.  THe problem is simply time to do it right.
    
    Hopefully, there will be time before the SDC ship to get it done.
    
    re: .2 item 4
    
    We say that the CRF file is not readable because we don't want to
    explain how to read it.  If we explain how to read it, someone
    will try to edit it.  (Someone will edit it anyway, but when they hang
    theirself, it is their problem...)
    
    If there was time, I would make it truly unreadable by throwing
    in lots of binary fields. 

    re: .4   Good!  That will do very nicely.  
    
    re.  .5  Hope you'll have time to fix it as you/we wish.  As to
             fibbing on the readability of the .CRF, I'd advise
             against it.  Just tell them not to mess with it, and
             why.  Or, as you mention, make it truly unreadable.