Conference vaxuum::document_ft

    If you didn't supply the arguments to a <table_row> in an argument
    list, then you would have to identify them as <column> or <cell>
    or something like that.  Either 
    
      <table_row>(foo\bar)
    
    or 
    
      <table_row><cell>foo<cell>bar
      
    It is a good habit when coding this stuff to start every list or
    table with the start and end.  LIkewise, the table row.
    
    Start with
    
    <table>
    
    <endtable>
    
    then go back and fill in the <table_row> tags.  Likewise, start
    the <table_row> tag with"
    
      <table_row>()
    
    and then go back and fill in the stuff between the parens.
    
    That is what LSE does for you when you call for a <table...
    or <list>.

    Great...if you're creating a table from scratch.  If you're inserting
    table tags into and around existing text, LSE doesn't help much.
    
    I don't see why
    
    <TABLE_ROW>column 1 \column 2 \column 3
    <TABLE_ROW>mumble 1 \mumble 2 \mumble 3
    ...
    
    isn't exactly the same concept as
    
    <LE>first thing
    <LE>second thing
    ...
    
    You're saying that an "argument list" in SDML MUST be in parentheses?
    I've got the same question: why?  Whether you delineate a <TABLE_ROW>
    by a ) or by running into another <TABLE_ROW> or into an <ENDTABLE> tag,
    it seems to me that you can still separate the columns by \ characters.
    You'd have to "push down" nested table context, of course, but you
    must do that anyway.
    The parentheses seem redundant to me.  
    
    I'm really not trying to give you a hard time Bill - you people
    have improved the product no end in the past few months.  It's getting
    really good.  But it still frustrates me a lot.
    

    Perhaps you can please people by permitting them to specify arg
    lists either in the current manner:
    
       <TAG>(...\...\...)
    
    or in a manner similar to lists:
    
       <TAG><ARGS><ARG>...<ARG>...<ARG>...<ENDARGS>
    
    That would have the following advantages:
    * It handles all the same lexical analysis issues as (...\...\...)
    * It should involve minimal change to your implementation of DOCUMENT,
      since it is easy to envision it as local to the lexical analysis
      portion and requiring no change to the rest of your code.
    * It makes short args convenient, with (...)
    * It makes long args convenient, more readable, and less error-prone,
      with <ARGS>...<ENDARGS>
    * It lets people (like me) who do things like putting lisp code in args do
      it without having to translate all the parens to <OPAREN>...<CPAREN>
    
    RSVP 
    
    Dan
       

    
    Your approach is something I've thought about quite a bit for the
    future, especially for allowing tables with more than 9 columns.
    
    on your parens: have you fallen into the trap of always using
    <oparen> and <cparen> in tables even when they match? The tags
    are needed *only* if an unmatched paren is in an argument...
    
    

    Before this goes too far in a one-sided manner, I vote for keeping
    <TABLE_ROW>(...\...\...) the way it is.
    
    Joe

        
      RE: .4
    
    Thanks for the info!  I'd gotten the impression from (mis?)reading
    the documentation that the only parens you could have in arglists
    were arglist delimiters for nested tags.  Knowing that any matched
    pairs of parens are okay will save me lots of pain.
    
    As for the <tag><ARGS><ARG>...<ARG>...<ENDARGS> syntax or something
    comparable being available for some future release, I honestly don't
    see why it would involve much implementation work.  You already
    have stuff to parse <LIST><LE>...<LE>...<ENDLIST>.  I would think
    that the only change necessary would be for the lexical analyzer
    to translate <ARGS><ARG>...<ARG>...<ENDARGS> into exactly the same
    thing it translates (...\...) into, *before* any other part of the
    DOCUMENT engine and tag definitions see it.  Seems like a small
    amount of work to me, though maybe I misunderstand something.
    
      RE: .5
    
    I don't understand your objection, unless you misread 221.3.
    It doesn't propose making any change at all to <TABLE_ROW>.
    In fact, it explicitly says that <TABLE_ROW>(...\...) syntax would
    still work exactly the way it does now.
    Why should you care whether it or any other tag accepts an arglist
    in a new format *in-addition-to* the existing format, in a completely
    upward compatible way that introduces a number of new advantages,
    and with no significant run-time performance degradation for users
    of the (...\...) style?
    ...unless, of course, you are the DOCUMENT lexical analysis developer,
    and just don't feel like making a small, transparent change to your
    code.
    
      RE: .3
    
    Here's another advantage to throw on the pile:
    * Machine-generation of (parts of) documents would be made much
      easier.  Any time there are special characters, you beg for trouble.
      Consider TeX/LaTeX, in which you get messed up by such common
      characters as $, _, ^, %, &, ....  DOCUMENT currently does a very
      good job with this.  The only thing (other than if you happen to
      have things that look like tags) you can get into trouble with
      are a few special characters in arglists.  .3 would permit you
      to machine-generate things in arglists, without worrying about
      running into those.

    
    I suspect the long-term solution would be to provide both mechanisms.
    I like the use of arguments, not just because it's what we are used
    to, but also because having things in arguments lets us manipulate
    them with the tag translator in a straight-forward fashion.