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
