I still think it's conceptually more logical that each child is considered a substitute (and by the way, the `<substitute>` element would be a great alternative to <if> in some cases, if extended to the rest of CSL). However, I must bow to the reference implementation, and I suggest maybe the written specification should be more explicit, ;-)
Now, I do have a problem is that this will requires quite a lot of work to make my processor work with this rule, but so be it... (Let me explain why. In the way the XML tree is treated, all elements are handled as much as possible independently of the context in which they are. For instance, the `<substitute>` element will ask its children, in turn, to evaluate themselves, until it finds one child that has a non-empty value; and when the `<choose>` element is evaluated, it's evaluated just like any other `<choose>` element, and does not apply any special rule to take into account the fact that it's within a `<substitute>`. This is what I meant by being more logical in terms of the XML tree, even if I totally understand it makes things easier to write, and I also agree that syntax brevity is a feature that often trump implementation complexity). charles On Oct 9, 2012, at 8:04 PM, Frank Bennett <[email protected]> wrote: > I read this exchange with a growing sense of relief. My initial > reaction was to assume the existing citeproc-js behaviour was a bug, > and to reach for the source code. The story rapidly grew more > complicated as I tried to dig into the problem -- and I was delighted > to find a reminder of what I should have remembered -- that the > current behaviour actually does make sense. > > Frank > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel -- Charles Parnot [email protected] twitter: @cparnot http://mekentosj.com ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
