Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 22:47:45 +0100 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id nAALlij9029151 for ; Tue, 10 Nov 2009 22:47:44 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id nAALi0Q4010269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 22:44:00 +0100 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id nAAGHAAE021466; Tue, 10 Nov 2009 22:42:31 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 376983 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 10 Nov 2009 22:42:31 +0100 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id nAALgVKt019157 for ; Tue, 10 Nov 2009 22:42:31 +0100 Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id nAALgRQA010330 for ; Tue, 10 Nov 2009 22:42:31 +0100 Received: by fg-out-1718.google.com with SMTP id e12so1284944fga.16 for ; Tue, 10 Nov 2009 13:42:27 -0800 (PST) Received: by 10.86.203.35 with SMTP id a35mr513459fgg.44.1257889347489; Tue, 10 Nov 2009 13:42:27 -0800 (PST) Received: from ?10.0.1.103? (219-90-212-151.ip.adam.com.au [219.90.212.151]) by mx.google.com with ESMTPS id e11sm9196425fga.7.2009.11.10.13.42.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Nov 2009 13:42:24 -0800 (PST) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 (Normal) References: <19189.17593.814557.704925@morse.mittelbach-online.de> <4AF5A79B.9040003@residenset.net> <19189.49743.74826.581704@morse.mittelbach-online.de> <004001ca6051$e9e35e10$bdaa1a30$@de> <19192.38156.431785.622764@morse.mittelbach-online.de> <002101ca61d4$f322ddf0$d96899d0$@de>, <20C53106-7650-4EAC-82C1-BEF0EFA17816@gmail.com> X-Mailer: Apple Mail (2.936) X-Spam-Whitelist: Message-ID: Date: Wed, 11 Nov 2009 08:12:17 +1030 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Will Robertson Subject: Re: an object type for heading commands To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -6.599 () BAYES_00,RCVD_IN_DNSWL_MED X-Scanned-By: MIMEDefang 2.65 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 10 Nov 2009 21:47:45.0194 (UTC) FILETIME=[6FD970A0:01CA624F] Status: R X-Status: X-Keywords: X-UID: 6158 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