Conference vaxuum::document_ft

    If you can run the file through ALL-IN-1/WPS-PLUS and get an ASCII
    file, then you can easily run through the file, marking the 'headings'
    as topics in an outline.  You can also easily take care of pictures
    at the same time (keeping them literal text).  Then, use OUTLINE
    to make an outline of the text.  Once you are in OUTLINE, you can
    take your pick of output formats, including either DSR or DOCUMENT.
    
    J

    Perhaps this discussion should take place in another conference,
    but ...
    
    Converting a plain text file to Outline sounds like a lot of work.
    Identifying headings and pictures can take a fair bit of time. Lists
    and tables would be a lot more work. Book titles and other emphasized
    text would be a tedious chore. I don't see what Outline offers in
    this context.
    
    Not that I have anything better, mind you. We've been struggling
    to get a DECpage (.xlt) to SDML converter going. In the words of
    one noter's personal name, ``So little time, so many ratholes.''
      

    
    DSR and WPS to DOCUMENT converters are on the list .. working...
    
    -pa

    Is the WPS-PLUS converter going to be a .WPL<->.GNC converter (or
    a .DX<->converter for that matter), or will there only be a .XLT->.GNC
    converter?  The problem with the latter is that it doesn't allow
    revisions using the original editor (I don't count including a .GNC
    file into a .WPL file to edit it using DOCUMENT tags as reasonable).
    I realize that there would be some loss of formatting (maybe), but
    I'm extremely uncomfortable with one way filters, in that they're
    far too restrictive.
    
    Joe Duncan @ NCO

    
    GENERAL does support <head5> and <head6>, as do all the doctypes
    that support <head1> through <head4>.
    
    patti

RE: .5

The purpose of the WPS -> SDML converter is to provide a migration path for
WPS users who need the advanced formatting capabilities which DOCUMENT
provides. That is necessarily a one-way path, because SDML has many more
text elements than the WPS editor is capable of representing (I suppose
you could have different rulers for every SDML tag, but how user-friendly
would that be?).

    Re .6
    
    Where is the documentation for <head5> and <head6>. I recently told a
    user that those depths weren't supported for standard doctypes, so we
    wouldn't be supporting that depth in local doctypes. (I thought it
    silly that people used those levels in Runoff, too.) 
    
    kh

    
    Just checked the documentation for T1.0, and indeed it does say
    heading-levels only up to 4. In fact, 6 are supported in all the
    doctypes. The reason? Six levels seemed to be required for some
    doctypes (particularly specifications), so for consistency's sake
    we just supported them in all. I think it's still reasonable on
    a local basis to publish guidelines telling users to stop at a 
    particular level.
    
    patti
    

    
    I'd cast my vote with .5 for a DX <-> GNC converter. Suppose one has a
    valuable source file with .GNC codes but doesn't have DOCUMENT? How do
    I extract the text? I can easily imagine a situation where a writers
    wants to extract the text in a .GNC source file for conversion to DX
    format (for example, converting .GNC to DX for filtering into DECpage,
    Interleaf, PageMaker, etc.). It would be a shame to enforce a one-way
    conversion when it seems that most of the work in a GNC -> DX converter
    involves throwing away formatting code that cannot be represented in DX
    format.
    
    

RE: .8 and .9



I can't tell the definitive source/standard, but it's always been my 
understanding that corporate standards state that header levels can go 
no more than 4 deep.   Maybe this is some military type standard, the 
capability of which should be limited to MILSPEC?  I'm only guessing, I 
don't know.   Then again, there are the external customers...


I don't plan to tell the engineers I'm working with on specifications
that 5 and 6 are possible; rather, I'll continue to educate them to
rethink the way they've organized their content. 


RJ

re: 53.8



First, let me start off by letting of some steam!

Hssssssssssssssssssssssssssssssssssss!

Good, now I feel better.

It is totally up to the user as to which levels s/he uses.
To put it bluntly, I consider it very user unfriendly for the software to make 
such a decision for the user in such general use tools as a GENERAL do type.

If you want t restrict it, and I would never do so, in a mumbo_jumbo doctype,
that might be acceptabele in some cases, but NEVER in a GENERAL doc type.

Hssssssssssssssssssssssssssssssssss!

Glad I got that off of my chest!

re: 53.11

No way.

I am a member of the Corporate Standards group.

We support the DEC reps on ANSI/ISO/ECMA/etc. standards committees.

It is common practice to use 5 or 6 levels in writing a technical standard.
We need that to be effective on standards committees.

MILSPECS use similar formats. I don't know (nor do I care) if they retrict
them to 4 levels. My recollection is that they don't.

However, that is not the issue!

Conformance to a standard does not mean that the conforming software MUST 
restrict itself to allowing only those formats permitted by a standard, rather,
it means that you have to allow the creation of conforming documents and need
not preclude the creation of non-conforming documents. That's up to the
(ab)user of the software, not the choice of the software.

Pause

Hssssssssssssssssssssssssssss!

End pause

Wow, this topic really gets me riled!

Ok, I've been duly re-educated, and I didn't even mind!  Your points are 
well-taken.

Didn't (nor ever do) mean to get anyone riled.  But hey, always glad to
help someone get the big IT off their chest!  Heaven knows I have enough 
of my own ITs!

Subject closed.

Sincerely (and that's no joke)


Rose

re: .10

The issue of bidirectional translation is whether the intent is to
perform modifications or not.  If you want to translate from format A 
to format B, modify B, then translate back to format A, you won't
necessarily recognize the new format A document.  It will have all the
"right" text, but the formatting commands won't necessarily look anything
like they originally did.  In fact, many of the formatting commands would
probably be missing.  This is because the mapping of SDML <-> DX (WPL) is
not a one-to-one onto mapping.  Translation without intent to modify could
be supported, although I don't know if anyone is going to bother providing
an SDML -> DX (WPL) converter.

-tl