To clarify ... On Sun, Apr 28, 2013 at 8:07 AM, 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?
When I used the word "disruptive" in this context, I was meaning WRT to compatibility, and therefore style and schema versioning. I realize for developers, it's not that big a deal. Do we have a clear policy on this? Does a change like this go in a 1.1 schema and spec, and do we create 1.1 variants of all 5000+ styles? Notwithstanding details, I think this is the core issue I see. On the detail you identify here, I see no problem with that example apart from the above .... > 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). Right. This is an example that conflicts with current design foundations in CSL. Now, if you all think that's a good idea, that's fine. All I'm saying is *be aware you are doing this, and be very careful.* CSL is now a mature specification, and elegant change management is the key challenge for you all going forward. Bruce > 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
