LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mime-Version:
1.0 (Apple Message framework v936)
Content-Type:
text/plain; charset=US-ASCII; format=flowed; delsp=yes
Date:
Wed, 11 Nov 2009 08:12:17 +1030
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Will Robertson <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
7bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (93 lines)
Hi Chris.

Didn't sleep much last night (heat wave in November) so apologies if  
there's incoherence below.

On 11/11/2009, at 2:17 AM, Chris Rowley wrote:

>>>
> 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?

I'm not sure that I'm sure. Are you sure that I'm not sure? :)

When I say "user interface", I mean the means by which the document  
author (the person typing in the words and the markup) types the  
things they type. (What the actual braces and slashes and optional  
arguments look like.)

But you're right that the decisions made when sorting out what the  
object looks like to have a top-down pressure on what the user  
interface ends up being. (Or "a" user interface, if you subscribe to  
the idea that these ideas might one day be general enough to support  
multiple and largely equivalent ways of writing our documents.)

Anyway, I think we understand each other even if our words are a bit  
fuzzy.

> 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:-).

Erm, well, we can take a look around and recognise that in most books  
and articles there's not too much information hanging off the bit that  
says "Chap 3. How to sleep. Or not." and then base the heading object  
off what we find. So "sensible" should be interpreted as "what we  
think happens most of the time" which then informs our heading object,  
which then spirals back to your interpretation of "only what we say is  
normal is sensible". Guess I'm trying to say that we're saying it's  
"normal" not arbitrarily but based on some sort of collective  
experience (and common sense).

> There is no need whatsoever to have a 'one object fits all'.

That's why I said "most" in that bit you quoted of me :)

>>>
> \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.
>
> 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.

I shall look forward to it. I get the impression our internal models  
of "what is a document" differ greatly although we obvious end up with  
a similar result most of the time.

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

I agree. I was just trying to explain why the heading object having  
eight or nine arguments isn't the terrible user-interface design  
decision it might appear at first. We're trying to sort out the  
"internal data model" (although I'm not sure if I'd put those words to  
it in a more lucid state) which is a simple list of information that  
will be partially (sometimes completely) supplied in some form by the  
user. But how it's supplied isn't of interest right now.

-- Will

ATOM RSS1 RSS2