Message-ID:  <E0xL6VE-0004cq-00@heaton.cl.cam.ac.uk>
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
In-Reply-To:  Your message of "Tue, 14 Oct 1997 14:28:57 +0200." 
              <v03110702b06911744b8a@[130.237.37.124]>
Date:         Tue, 14 Oct 1997 13:55:10 +0100
From: Robin Fairbairns <Robin.Fairbairns@CL.CAM.AC.UK>
Sender: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
To: Multiple recipients of list LATEX-L
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
Subject:      Re: LaTeX journal and publisher macros
Status: R

Hans Aberg writes:

>   The correct way to understand if various object oriented techniques and
> such are the right things, is to make a research prototype and then
> experiment with that: Such techniques are otherwise difficult to
> understand.

What I said was, that Hans's proposal was interesting but that I
hadn't concluded that it was the `right way forward'.  I meant exactly
what I said: I didn't mean I didn't understand it.  I'm attracted by
the constructs that David Carlisle produced in his frontmatter
proposal, which addresses the problem in a slightly different way.
David's proposal wins (IMHO) if we're not likely to run out of name
space.  If we are likely to run out of name space, Hans's proposal
(which I would identify with

  @InCollection{saltzer:names,
  author =       "Saltzer, J. H.",
  title =        "Naming and {B}inding of {O}bjects\nocite{bayer:os-advanced}",
  crossref =     "bayer:os-advanced",
  chapter =      "3.A",
  pages =                "100--208"
  }

  @Book{bayer:os-advanced,
  title =        "Operating Systems: an Advanced Course",
  publisher =    "Springer-Verlag",
  year =                 1979,
  editor =       "Bayer, R. and Graham, R. M.  and Seegmuller, G.",
  volume =       60,
  series =       "LNCS"
  }

which is the classic naming paper) comes into its own.

There is no problem in my mind with implementing Hans's suggestion
(though I would be interested to see his implementation).  There is a
problem with knowing whether it's necessary.  I believe it imposes an
extra burden of understanding on the user (and hence of documentation
on the implementor), so I don't want to rush into its use without
being entirely sure that it's the right thing.

Robin