LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Fri, 21 Aug 2009 21:34:41 +0200
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=us-ascii
From: Frank Mittelbach <[log in to unmask]>
Parts/Attachments: text/plain (112 lines)
I haven't been through with reading all the discussions on xparse, but before
I start commenting on one or the other aspect that got discussed I want
briefly point out some points on the history of xparse and the thoughts we (or
I?) had when it was originally written.


When we initially developed the first version of expl3, template and the like
I was thinking that the language should be organized into different layers,
each focussing on different aspects and as a result with different interfaces
and features.

layer 3

On the bottom layer there is expl3 and most of that (though not everything) is
now available and (I guess) largely to our liking. The purpose of that layer
is to support actual programming by providing the right kind of data
structures, some better support for the problem of dealing with macro language
of a TeX-like engine and its particulars.

layer 2

The layer above I consider the layer that provides design support and by that
I mean it provides higher-level customizable objects/elements. Those objects
would be recognizable typographical elements of documents and/or identifiable
sub-parts of those. For a document of a certain type one would need a certain
set of those elements to generate a typographical representation of the

The interface for using these objects would be simple and uniform, e.g,
arguments of objects always mandatory, a small number of well-defined special
values (e.g., \NoValue for a missing value, etc.)

The configuration possibilities of these objects all follow a single concept.

To define such objects a person would need to be able to express him/herself
in the programming language of layer 3.

In short what we do have of this layer (and is currently dissected by Joseph)
is the template interface; it may need other things, e.g.,  the concept of
template may not fit in the present form for aspects like guiding page layout.

layer 1

Next layer is the design layer. 

In this layer objects from layer 2 are selected and instantiated to implement
a particuly layout (design).

As long as layer 2 provides the right kind of objects (with the right kind of
customization possibilities) there is no need for a designer to hassle with
the particulars of the layer 3 language or do any programming. Instead he or
she would do selecting and configuring only. Of course if a certain layout
can't be produced from existing objects then somebody needs to provide it on
layer 2.

What we have from this layer is again currently part of template.dtx, e.g.,

layer 0

This layer defines the document structure, that what kind of document elements
exist and their relationship as necessary (but without offering a
specific user-level representation yet). This is  done by attaching semantics
to named instances (those layout characteristics would be defined in layer 1)

important about this layer is that it doesn't say anything about layout or
typographical representation but is solely concerning with  defining something
like a DTD for a certain typoe of documents.

currently that layer is represented by \DeclareTemplateType (from
template.dtx) and by the implementation bodies of document-level commands
defined with (for example, xparse). 

layer -1

this is finally the layer that offer user-level syntax, i.e., defines command
names, parsing rules, optional arguments, what have you. So this is what makes
up the buld of xparse functionality (defining parsing and command definition)
and the xparse interfaces \DeclareDocumentCommandInterface and
\DeclareDocumentCommandImplementation are really nothing other than a so far
not yet fully sorted out attempt to do a split between layer -1 and layer 0.


I don't think I have given a very good presentation of the ideas, but I hope
that they nevertheless got clear enough, 

As a short summary:

 layer -1 = user interface definition for layer 0
 layer 0  = DTD document type definition (no layout aspects)
 layer 1  = layout/design definition for given DTD from layer 0
 layer 2  = predefined, customizable templates for use in layer 1 (applicable
            to more than one DTD)
 layer 3  = programming constructs to build objects of layer 2


ps. i hope i haven't sprinkled in "not"s where they didn't belong or left them
out when I meant it