Am 27.01.2014 19:02, schrieb Sean Allred:
> Hello everybody,
> I recently asked a question on TeX.SX about potential graphical
> interfaces for document authors/designers with the new layering system
> of LaTeX3, but Joseph pointed out that it was probably more suited for
> this list.
well, as SX draws some interest around expl3 and LaTeX3 architecture and
ideas and has a fairly broad audience it is not necessarily the wrong
place to record what has been thought on those topics in the past.
However, it is clearly not suited as a discussion forum
> I reproduce it below:
>> With the separation of document authorship, design, and
>> implementation, is a graphical tool for the end-user within reach?
yes (well depends on what is called within reach :-)
>> LyX tries to do this today, but LaTeX2e is not well-designed for such
>> an approach. In essence, this is what LaTeX3 tries to fix: authors
>> must not be concerned with how their document looks in contest with
>> the actual content of their work. While LaTeX2e did successfully
>> separate markup from implementation, it could not cleanly separate the
>> *design* from its implementation (and everyone and their mother has a
>> word to say about design---this isn't going to change). The layers of
>> LaTeX3 are designed to separate the implementation/coding from the
>> design from the content. The amazing work so far on LaTeX3 is proof
>> enough that many people believe this separation is possible---myself
that makes at least 2 :-)
>> Given this ideal of separation, will it be feasible for there to be
>> environments in which to author and design LaTeX documents in a way
>> that will put the power of LaTeX and `expl3` in high demand?
> So there you have it---given that the entire LaTeX3 system (looking also
> at `xtemplate`) seems to be going toward an system that has entirely
> different interfaces for more well-defined roles, has a truly graphical
> front-end (*not* a front-end such as LyX) been brought up?
if brought up in the sense of a wider discussion, then no, but it was
definitely at our minds (mine for a start) when attempting experiments
with xtemplate and LDB
> The `expl3` underworkings of the system must still be used directly as
> text---it doesn't make sense any other way---but there should be no
> reason an author should see this. The simplicity of `xtemplate`s
> interface would allow for easy parsing, and graphical interfaces to
> objects/templates might be feasible.
exactly, even if xtemplate as it is now has its fault and should not be
the final model, but (most of) the underlying ideas could.
What I have in mind here is something a bit in the spirit of "Batch
Basically, if you think in terms of current xtemplate then templates
define objects and within some limits support modifying their
representation by setting layout parameters that turn such a generic
template into an "instance" with a fixed presentation.
Now what one could think of a template being a configuration spec that
defines the boundaries (what parameters are available, what the value
space is (eg limits, type of values), and some explanation what it does,
default values (if any).
That kind of configuration could be read in by a GUI program that then
supports via sliders and what have you turning a generic template into
One step further, the idea or say the realization is, that you can't
really have "monster templates" that do everything, but that instead if
the material gets complex enough, say headings, then you will end up
with a bunch of templates all implement headings of some sort and all
being interchangeable but all generating very different layouts.
To follow up on this idea, an intermediate step of such a GUI could be
to allow for selecting a template or replacing a template with a
different one (for the same object type) thereby changing the underlying
set of parameters.
- The GUI could read in an existing "class instance" which is
- a spec of "document class definition layer" spec (abstract) 
+ plus its realization with a bunch of templates and their chosen
values turning the templates into instances
- The Designer/(or the author acting as one) could then modify
parameter values, or could do more drastic steps, by selecting a
different template for some object and then getting potentially
different parameters to set or change (from their default)
- upon save, what gets written back is a new/modified "class
instance" which is directly executable by L3 (ie with the current model
a bunch of \DeclareInstance jadajada
- alternatively one could read in "just" a "document class definition
layer" spec  in which case the GUI would display available templates
to chose from for realization
now there is the small issue of LDB ideas which somewhat complicates or
changes this picture a bit but on the whole this is what I think it
should look like eventually.
Now the template stuff is perhaps not formal enough yet, but it was day
one written with this kind of idea in mind
 for those who wonder what the hell a document class definition layer
is .. see for example