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
