LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Tue, 10 Nov 2009 22:57:42 +0100
text/plain (184 lines)
Chris Rowley writes:
 > >>
 > At the level that Frank is taking about, he's discussing what  
 > different sorts of information can be used to format an arbitrary  
 > section heading. But the important thing to remember is that this is  
 > not the user interface.
 > >>
 > Are you sure about that?

well he is, I guess and yes, that is the way I look at it. We are not talking
about a user interface at all.

There is a relation to user interfaces and I welcome people's information on
what they like to see on user interfaces as that gives us a range of what is
potentially be sensible to cover. But the mandatory arguments to an object
type that is declared with \DeclareObjectType have no directl relation to a
user level interface.

 > >>
 > The idea of an "object type" in xtemplate refers only to the  
 > information given to it,
 > >>
 > It would be good if that were true but the impression I got from the
 > discussion is that this thingy specifies more than this about the 'document
 > interface' one of many 'user interface' around, I guess but probably what
 > most people think of as 'the user-interace', of current latex at least.  

then it is about time to squash that. Let me try to rephrase what the
arguments of an object type are:

 - they are arguments that receive document data (if a document interface
   supports passing document input this way)

 - each argument should have a well-defined semantic meaning

 - the arguments may accept special data, such as \NoValue if the document level
   interface  doesn't pass any real data

 > >>
 > not how that information eventually ends up  
 > in the typeset document.
 > >>
 > Agreed, but that is not usually thought of as interface, is it?

??? I can't parse that comment ???

 > Of course the 'information supply' is an important part of the procesing
 > that leads to the typeset document (or other current outputs from LaTeX
 > code:-).  You cannot do anything (eg format) information that is not
 > supplied and it must be suppied in suitable labelled containers too.

the purpose of the object type is to describe/formalize the information
supply, e.g., we call something an object of type "X" if it conceptually does
"Y" and accepts inputs "A" "B" "C" with the a specified semantic meaning.

A template for object type "X" then provides a customizable (on the design
level) implementation for that object type and an instance for type "X" is an
instantiation of some template for object type "X" that freezes the design
parameters of that template in some way. It this formats an "X" object by
receiving the document input in its arguments "A" "B" and "C" and does some
formatting that hopefully can be interpreted as providing "Y".

 > OK, since I am here I will comment on the more substantive bits too.
 > >>
 > But it's important to design the "heading" object  
 > sufficiently generally that it can handle most sensible document  
 > designs.
 > >>
 > I am deeply unconvinced by this statement unless I interpret it as a 
 > truism, thus: 'sesnible document designs are precisely those that will be
 > covered by this one thingy (is it really an object, in the normal
 > informatics meaning of that word ... ask C Mittelbach:-). 

well I just did ask her, and she thinks you haven't got to anything
substancial yet :-)
 > There is no need whatsoever to have a 'one object fits all'.

no there isn't but there is a huge need to have a common language where a good
range of thingies are fitting together and not everybody invents its own
abstraction and its own naming etc.

to stay a little more practical: in LaTeX 2.9 and later in 2e Leslie came up
(beside other things) with a spec for what document input a heading is
supposed to accept and what data an article title should be concerned with.
As far as the headings were concerned its object type definition was something

 - it accepts a maint title
 - it accepts a toc + running head title (overwriting main title if present)
 - it can request that the heading is unnumbered

2e also defined a syntax for this on document level eg \section * [toc]{main}
but he could have come up with something totally different on the document
level and the spec above would still hold.

Now the spec above may not have been perfect and many people think that some
more flexibility would have been better. However, it did one thing perfectly:
nearly every LaTeX class accepted the above as the object type spec for
headings so that it was extremely easy to replace one layout with another
without the requirement to change the source. (yes all such classes also
implement the user level syntax ie \section *[]{} but this because 2e didn't
have a clear separation here)

the second example is \maketitle where the LaTeX class spec for the object is
really very limited and already early on journal classes started to add to it
by requiring to accept and format the abstract for example. As a result those
classes can't be exchanged because their object types do not agree.

so basically what I'm saying is that I think it is important to find good
object type specs that cover the need of a good range documents. There is no
way to have a 'on object spec fits all' but that is a good way I think to fit
a lot without providing too much burden. Finding the balance here for what end
up being standard specs is important and as far as a heading object is
concerned I think the standard spec should be richer than the three bullets
from the 2e spec

 > >>
 > \section{Main Title That is Very Long and Involves Lots of Things}
 >    [
 >      label = main-title ,
 >      toc-entry = Main Title That is Very Long ,
 >      header-entry = Main Title ,
 >      numbered = false
 >    ]
 > >> 
 > that is fine as an example of a (classic LaTeX) document/user interface.  

probably and it wasn't meant as anything else by Will

 > I shall say more inanother post on a slightly different point about the
 > structure (in the sense of abstract stuctured dosumants) and the nature of
 > sectionhead-like elements.

let it come then, please

 > >>
 > Internally, this might end up as the  equivalent of
 > >>
 > No, no, no!  Internally the syntax matters not at all in this context.

no no no ... I can do that too.  Will was only giving an example on how
something from some external syntax would translate to the internal one and in
that context it matter a lot. However, if you look at it more abstractly then
yes what is important is what the input stream are and what they mean not how
they get represented.

 > What you need to decide is at a higher level of abstraction what the
 > structure of the information is (technically what is the content model for
 > this subtree and which bits of information are values attached to nodes in
 > the tree rather than the content of nodes).

very flashy but where's the meat? is that in very nice words what we tried
initially, like what information should be input to a heading object?
 > But a comment on the syntax: internal things do not need to be locked away
 > in what look here like 'tex parameters'.

no but there is not harm in making a decision and going with it. for a change
we do (by the end of the day) want to do some formatting and for that we
haveto settle on an internal interface. And guess what we decided to make it
look like tex parameters (as we are going to use some).

As you correctly say, the how the format is doesn't really matter, so why do
you care now?

 > More soon, I hope, specifically on the information (and layout?) structure
 > of 'sectioning and heads'.

let it come then