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 like - 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 cheers frank