On Apr 28, 2013, at 5:00 PM, Bruce D'Arcus wrote: > 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.
That was my misunderstanding then, my apologies. I had the feeling, during the discussion, that the original proposal was marked as clearly introducing new practices (in particular the variable-all attributes etc.) when I really didn't see how it differed from the current specification all that much. I think versioning is a big deal for developers, because it's extremely painful to support different versions (for example, to support CSL 1.0 ordinals with two different algorithms). This is exactly why I was in very much in favour of the proposal: it offered more flexibility and can be implemented with a single algorithm that still covers the current version – that's a very big plus in my book, but it looks like we're moving in a different direction now. > 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? I think Rintze makes a good point there: by creating a 1.0.1 branch it is easy to retain all styles; it's even possible to accept updates on that branch. Whereas new features go strictly into master and are not merged back to 1.0.1. > 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. Yes absolutely. Sylvester ------------------------------------------------------------------------------ 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
