Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id s7VGthl8001973 for ; Sun, 31 Aug 2014 18:55:49 +0200 Received: from relay.uni-heidelberg.de ([129.206.100.212]) by mx-ha.gmx.net (mxgmx105) with ESMTPS (Nemesis) id 0LurzJ-1YNYdc0yWn-0104im for ; Sun, 31 Aug 2014 18:55:37 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id s7VGr0PO017405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Aug 2014 18:53:00 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s7VCDtbC025571; Sun, 31 Aug 2014 18:53:00 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 11284850 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sun, 31 Aug 2014 18:52:59 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s7VGqxUp008691 for ; Sun, 31 Aug 2014 18:52:59 +0200 Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id s7VGqled017372 for ; Sun, 31 Aug 2014 18:52:50 +0200 Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id A8D58678058 for ; Sun, 31 Aug 2014 09:52:46 -0700 (PDT) Received: from smbp.home.seanallred.com (pool-108-51-157-100.washdc.fios.verizon.net [108.51.157.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: tex@seanallred.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 6D967678057 for ; Sun, 31 Aug 2014 09:52:46 -0700 (PDT) References: <53F667E1.8080909@morningstar2.co.uk> <5B8B103B-5CCD-490E-9177-F1B8F65C26BF@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin) MIME-Version: 1.0 Content-Type: text/plain Message-ID: Date: Sun, 31 Aug 2014 12:52:45 -0400 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Sean Allred Subject: Re: Thoughts on xtemplate To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: (Will Robertson's message of "Sun, 31 Aug 2014 18:44:47 +0930") Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:L16T47aYlfs=:zsZ1nqNAjwSLoTU+hxq941uN5x tHgLA7gamvn8PlK9gZ6BtSLOKYE1hbcs0uIrOXFKDrgdaSiUQlXkgCqA6MhJO+yGwsNk+ATEl 5xDdjlVZkQD1f6lBCjorbebt48SQv3gRZ5wxSbtHT31ItoX/rHHz1FMc2C64ppvTHlt9jyDmW wYu84GVB3s9xDpp4BWfICQLOAdtyhYowhiAhxuuE+wSFuqT1rJ9jsFaQ1PSoHiggQPLW4bVoT qp9MyRf/LtQGet812neQXl9tvS+vVjm4du54u3eZYyL7LuKYVY4gHNzGdUFoBPRVeNHJeaf+d XtMOAZr9ixYRFLYKSU5SI/oOfI6aJhsvFdYh/OUtc81c7vmQp5X6lTPgm2ECLxQEayxUI63pH v5Q6CqabK/8mSUl3mCr8ynUSWarcA1Lx9TqycuYuwh0gBBQKNWUwNUmRB0d+qm4D/NIbnA6hx j1JMwmkL1Zwoy1HNRsiuZSVnjuQtKrtiVRnKEkjp6Rk2Lpn1r3MIr4wfdp4dtB4GcLWA1GcES CVNWrKfjDKkP5eYU6urrCkqM935myjPPOwMnLKcZyiNNCtK7sDJ4S2BJZi0ZLxwBxctYaZVJS zuSw50+Ai9X6XidYg0WifWvnuiODn3pTSi4YAy9w8AX+G49jhb0CGMzvyNjQHEJjxOLT5TPiQ JIpo0Va2tukr7DHISpyxtUuD3+HetrobxIbcqf2428ISmnHP+G/6Wv95bPK6ZJ/NlqxXIjx0B 39LvDXgOIZUaRh+boW7ht1BX0RL5Zy+eYY3zANFysdXHLyxaj5dl5XAN6zAq0O3z2aO4rdzx8 CUgJvEU/kG022wDdJTIqC7SvcCeL8B7L4FHCYxzgAFlo9VmMkGxSmETeQiXDNWznzD/u1Vp08 ZzJ+46KfWC8sWj/bMxhy1kmCfRBGazp2sTWKM52+61nghacui61cHPabnubj9B+8U31v3BmVQ 88ikQVANXfeTr+FWiORVTEATCBvQ33nAymgDv4qjQDao9NifWK9UrvVoaVI6OdZId+HMpSQsZ 7Acg9Yh8odukpmCJLxEs0W31C/yVz9YzG/2qmEaydc85ZItssk/vO1mIRJe4bZ8wGbmw71b0d 7q69STGqEDUcKqKf5VR0j0hxxOsMLvMFnqgO3MSY/yTwLtOXNmlqyeU5RpvtN7NX5XnAa6RgG 7+IN9HQlwljWZZWtWi1O4CG9Eo7UCEpTBwJX1pSXsKbExMMsV9QNqwonJwT7ezrVjBaI9xlZc HLgnrLmdR32ZxymFZ+DRABsxyDX2SH2w3xRlKTOraiYYO5e1rQCABNIHYume4KF89S5gR5Zkt sD2+6pQLD7m+l9bE1OyjdK/+XPZupAnSR9ws8lgAUCgLkd+RIwjfIkHSLVn7IrC9JdPUr58Wc BiqEOmNdrP7TjB2m/wBIyQR7nvrTOyPWeVjvSgqM8CyY4OiIAXqkhW0QcGfQoDnZWOHTQd/sa fJb0YLjWNjCjD9aUp9GA2HqPmuLg6iek4v4TrTlrZ79k+3KZIi6f+QhO0i2r309nxXq+RdHQ= = X-UI-Loop:V01:Q0uqlbM+Rq0=:59ij/g+vscpyeJZ/qoqrUPLG0bicsTQwR3iwGMj1YoQ= X-UI-Out-Filterresults: notjunk:1; Status: R X-Status: X-Keywords: X-UID: 7582 Hi Will, > Like Frank said earlier, please don't take any lack of comment from me > as disinterest --- it's unfortunately a busy time for me. No worries at all --- I'm just happy that I've had a lull in my own work to think about this some more. So it goes :) > Correct me if I'm being daft, but doesn't "requiredness" need to be > checked at the template not object level? [...] Depending what type of > template you choose to typeset the object, you may or may not end up > using the various pieces of information. Oh, you're absolutely right --- I never thought about it that way. If this idea is used, templates would definitely need to have some way of declaring which object properties are required. But perhaps... > Or perhaps both objects and templates need to have a concept of which > parameters are required, and only work together if they match > appropriately. ...there could be a combination of the two, with the current concept of 'absolutely required' elements --- those properties without which the object is meaningless (like a section title). I think the 'matching' idea might be a maintenance nightmare, but I think the idea would be useful as some sort of 'inheritance' idea. Then again, this is implementing a feature that is emphasizing an already existing idea (assuming templates are given a sense of required properties). While I really like the "don't repeat yourself" of having required properties at the object level, I'm not sure it's worth the added language complexity. I'm not saying it's a bad idea, I'm just saying I can't quite envision how it would play out in the end. * * * Perhaps something like \DeclareObject { name } { first : tokenlist , middle : tokenlist , last : tokenlist , } \DeclareTemplateInterface { name } { full-name } { first, last } { reversed : boolean , first-name-format : tokenlist , middle-name-format : tokenlist , last-name-format : tokenlist , } I would note that this does fit well with the existing xtemplate interface. Normally, we would issue \DeclareTemplateInterface { name } { full-name } { 2 } { ... } to indicate that there are two required arguments. The required arguments listed in the above syntax is (conveniently) in the same position. My immediate concern with this is the idea of (co-)dependencies. Perhaps something like this can express those: \DeclareTemplateInterface { name } { full } { last } { middle : first } { reversed : boolean , first-name-format : tokenlist , middle-name-format : tokenlist , last-name-format : tokenlist , } Where 'last' is the only *required* property and to provide 'middle', you must provide 'first'. Perhaps lt3graph can be leveraged? Just thinking out loud here. Perhaps this kind of co-dependency isn't really needed to begin with, but I suppose it's something to keep in mind. If this was used, there would have to be some sort of dependency-cycle checking going on at declaration time, but that's just a detail. * * * I'm interested in what you're thinking though: > Or perhaps both objects and templates need to have a concept of which > parameters are required, and only work together if they match > appropriately. What kind of syntax do you have in mind? It might make more sense. * * * Thanks again (everyone --- past, present, future) for giving this a hearing and offering your own ideas. :) Best, Sean