I won't argue that CSL development is sometimes a little chaotic, but personally I like to first brain-storm about possible solutions when a (perceived) need comes up, and then trace back to see how the somewhat polished solutions could fit in the scheme of things. It makes it easier to compare the old to the new. Frank and I did this a lot for CSL 1.0 and that worked out quite well.
As feedback on Frank's latest proposal, I disliked how the multiple cs:condition elements weren't separated from the following rendering elements. I suggested that this could either be solved by introducing a wrapping cs:conditions element for the cs:condition elements, or a cs:then element for the rendering elements. These options can be seen at https://gist.github.com/rmzelle/5474220 (first, Frank's latest proposal; second, cs:conditions; third, cs:then) Also, I'm not currently convinced that we need nesting cs:condition elements to get NAND functionality. If we (initially) can do without nesting, so much the better. Rintze On Sun, Apr 28, 2013 at 9:05 AM, Frank Bennett <[email protected]> wrote: > We'll see how it goes. There's no rush, and feeling out the territory > of possibilities is good for us. From work on the mockup, I'm learning > how much flexibility is needed to flatten conditional nesting for at > least some of the more challenging requirements. Once I have untangled > some of the code, I'll certainly check to see if the initial proposal > would do as well. > > I've been feeling the need for extensions to conditional logic for > quite awhile now, and it's really great to see active discussion of > the issues. > > Frank > > > > On Sun, Apr 28, 2013 at 9:51 PM, Sylvester Keil <[email protected]> wrote: >> >> On Apr 28, 2013, at 2:35 PM, Frank Bennett wrote: >> >>> For what it's worth, Rintze and I have been kicking around some >>> refinements of the later proposals off-list. I've started working >>> through some of the logic in a thorny Bluebook-compatible style, to >>> see how one of the more promising patterns would play out in the wild. >>> It will take a few days for the refactoring, and I may do some coding >>> to get it working, to offer test samples. >>> >>> Nothing to show yet, but it's looking good in the mockup so far. I'll >>> try to post again in a week or so. >> >> As I said in earlier, in my experience all the instances where we have >> optional nested elements always lead to very unsatisfying implementations – >> at least I have been unable to come up with an elegant solution (I'd be glad >> to hear how others have approached this problem). >> >> As things stand, I would be very unhappy with a solution where the >> conditional node has to fetch information from optional child nodes in order >> to evaluate its own condition – the only reason I spoke up was because I saw >> some of the proposals going into that direction. If there is an elegant >> solution to this problem, all the better, but I would like to see actual >> code to illustrate it, that's all I wanted to say. >> >> >> >> >>> >>> On Sun, Apr 28, 2013 at 9:07 PM, Sylvester Keil <[email protected]> >>> wrote: >>>> Bruce, I am in full agreement with your points regarding the design >>>> process. >>>> >>>> The concerns you raised are very important (who does the change benefit >>>> and how? what are the costs? do the benefits outweigh the costs?) but the >>>> one on which most emphasis was placed in the discussion (or so it seemed >>>> to me) was the proposal's alleged disruptiveness. >>>> >>>> That's what I wanted to draw attention to. >>>> >>>> Or, more to the point: how exactly does the trailing '-all' etc. make >>>> things more complicated in a meaningful way? >>>> >>>> Currently we have something like: variable="x y z" and a processor must: >>>> >>>> - split the value into tokens >>>> - fetch data from the citation item according to those tokens >>>> - join the evaluated data based on the value of the 'match' attribute >>>> >>>> Now, with variable-all="x y z" the processor must: >>>> >>>> - split the value into tokens >>>> - fetch data from the citation item according to those tokens >>>> - join the evaluated data using logical AND semantics >>>> >>>> Why is that so disruptive as opposed to the current specification? >>>> >>>> The main change required to implement the original proposal was actually >>>> that the evaluation of all conditions can not be calculated in a single >>>> iteration anymore, but with one iteration per attribute (variable, >>>> is-numeric etc.). This leads to a slight change in how the 'none' matcher >>>> must be handled to avoid double negations. In my experience this was the >>>> most disruptive aspect of the proposal, but was not even tackled in the >>>> present discussion. >>>> >>>> The even bigger change is probably caused by the 'not:' prefix (at least >>>> in the Ruby implementation that was the case). >>>> >>>> Please don't get me wrong; I fully agree with what you're saying about the >>>> process in general and I realize that new features should only be added if >>>> they bring a real benefit to the language – all this should be discussed >>>> in turn. >>>> >>>> But if we are dismissing requests because of implementation-level concerns >>>> I would like to see more examples explaining those concerns. Especially >>>> when the request comes with two concrete implementations, with unit tests, >>>> is backwards compatible (in the sense that a processor can process styles >>>> with or without the new feature using the same algorithm) and when the >>>> ensuing discussion puts alternatives on the table that personally I find >>>> to be far more disruptive than the originally requested changes, which, in >>>> my opinion strike a good balance between the two possible approaches >>>> (i.e., putting conditional logic into attribute values at the cost of more >>>> difficult validation and putting the logic into additional attributes or >>>> nodes at the cost of reduced readability and – in my personal opinion – >>>> less elegant implementations). >>>> >>>> Sylvester >>>> >>>> On Apr 27, 2013, at 5:50 PM, Bruce D'Arcus wrote: >>>> >>>>> With the caveat that I'm distracted with other things, and so have not >>>>> followed this in detail ... >>>>> >>>>> But part of what I will say below is suggesting that the process >>>>> should be easy to follow for people who aren't following closely. >>>>> Right now, it's not. >>>>> >>>>> On Sat, Apr 27, 2013 at 11:12 AM, Sylvester Keil <[email protected]> >>>>> wrote: >>>>> >>>>>> I'm sorry I'm a little late to join the discussion. I'm very much in >>>>>> support of the idea of more expressive and powerful conditionals. As >>>>>> Frank mentioned, I already implemented the original proposal. I also >>>>>> like Andrea's and Frank's version that would go towards a single >>>>>> condition attribute – that would be more complicated to implement but >>>>>> probably easier for style authors to write. >>>>>> >>>>>> What I do like about the current conditionals (and also about Frank's >>>>>> proposal) is the high-level structure: >>>>>> >>>>>> <choose> >>>>>> <conditonal block> … </conditonal block> >>>>>> <conditonal block> … </conditonal block> >>>>>> … >>>>>> <conditonal block> … </conditonal block> >>>>>> </choose> >>>>>> >>>>>> That is to say, one clearly defined root element per conditional branch >>>>>> with no nested children. I think this is easy to read and easy to >>>>>> implement. >>>>>> >>>>>> I am not in favor at all of adding new (optional) child elements like >>>>>> <and> <or> etc. In my experience, dependencies between nodes always lead >>>>>> to less straight forward and less elegant implementations and >>>>>> consequently to more errors. >>>>>> >>>>>> I also don't think it's fair to use XSLT as a measure for how easy it is >>>>>> to implement a feature cleanly unless you provide an actual XSLT >>>>>> implementation. If we wanted to pick one language for such measurements >>>>>> I would suggest to use Haskell for now, because it is a functional >>>>>> language and we do have an actual implementation to look at. >>>>> >>>>> The objection to tying future evolution of CSL to a particular >>>>> implementation language is reasonable. On one had, I was simply >>>>> explaining the design, since it was first implemented in XSLT. >>>>> >>>>> But I still think it's reasonable to point out the current design puts >>>>> no processing logic in node values, and that the original proposal >>>>> here did. I am, I think reasonably, urging caution about changing >>>>> this. >>>>> >>>>> Back to process. I strongly suggest going forward you adopt a standard >>>>> process that starts with clearly defining the problem you're trying to >>>>> solve, and why. >>>>> >>>>> So, first big question, that I'm not sure has been explicitly >>>>> addressed: why are we contemplating this change? Who does it benefit, >>>>> and how? >>>>> >>>>> Second, what costs would come from adding a change like this? How it >>>>> it going to be folded into schema and style versioning? >>>>> >>>>> Third, do the benefits really outweigh the costs? >>>>> >>>>> My view, for example: >>>>> >>>>> If all a new proposal does is make styles less verbose, then that's >>>>> not a compelling enough reason to make a disruptive change. >>>>> >>>>> If, OTOH, the changes also make possible new functionality, with >>>>> demonstrated need, then the rationale becomes more compelling. >>>>> >>>>> Bruce >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Try New Relic Now & We'll Send You this Cool Shirt >>>>> New Relic is the only SaaS-based application performance monitoring >>>>> service >>>>> that delivers powerful full stack analytics. Optimize and monitor your >>>>> browser, app, & servers with just a few lines of code. Try New Relic >>>>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >>>>> _______________________________________________ >>>>> xbiblio-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Try New Relic Now & We'll Send You this Cool Shirt >>>> New Relic is the only SaaS-based application performance monitoring service >>>> that delivers powerful full stack analytics. Optimize and monitor your >>>> browser, app, & servers with just a few lines of code. Try New Relic >>>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >>>> _______________________________________________ >>>> xbiblio-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel >>> >>> ------------------------------------------------------------------------------ >>> Try New Relic Now & We'll Send You this Cool Shirt >>> New Relic is the only SaaS-based application performance monitoring service >>> that delivers powerful full stack analytics. Optimize and monitor your >>> browser, app, & servers with just a few lines of code. Try New Relic >>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >>> _______________________________________________ >>> xbiblio-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel >> >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >> _______________________________________________ >> xbiblio-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
