For 3, the spec says "If cs:substitute contains multiple child elements, the first element to return a non-empty result is used for substitution."
I'm pretty sure "the first element" is meant to refer to the first direct child element of cs:substitute that returns a non-empty result. So it should return the output of the entire "editor" macro, process both cs:names elements, and print the "editor" name variable twice. --- For 2, I agree with Sebastian. I can think of no reason to treat cs:label different, and we should fix the spec here. It was probably an oversight. --- For 1, the spec says "When an inheritable name attribute is set on cs:style, cs:citation or cs:bibliography, its value is used for all cs:names elements within the scope of the element carrying the attribute." So when cs:substitute calls a macro that uses cs:names, I think it would be most consistent if the cs:names element in the called macro would not inherit any attribute settings from the cs:names element that is the parent of cs:substitute. However, it probably should respect any inheritable name attributes set on cs:style, cs:citation or cs:bibliography. Rintze On Fri, Jan 24, 2014 at 5:06 PM, Frank Bennett <[email protected]> wrote: > Sylvester writes: "The spec says, the first element to return a > non-empty result is used for substitution. In this case, this is the > editor macro which actually prints the editor twice!" > > The citeproc-ruby behaviour seems correct, I think. Shall we amend the test? > > On Sat, Jan 25, 2014 at 3:05 AM, Sebastian Karcher > <[email protected]> wrote: >> In reverse order: >> >> Like Sylvester I'm confused about 3) as well and would have expected this to >> produce duplicate editors (as the editor macro by itself does). >> >> FWIW, I just tested this in my Zotero install and it doesn't actually >> produce the test result. I always get "Jane-girl Doe editor" even for books. >> >> Re 2.) We've been writing all styles assuming that the label node is >> inherited. I assume that is an omission in the specs, I'd suggest just >> adding that. >> >> Re 1) I'd go with your original hunch and not inherit anything that's >> explicitly set in the child node. If people use macros in cs:substitute, >> that's presumably precisely because they want to _prevent_ inheriting >> attributes. Otherwise they could just use cs:names. Again, making this >> explicit in the specs would be a good idea. >> >> Sebastian >> >> >> >> On Fri, Jan 24, 2014 at 10:21 AM, Sylvester Keil <[email protected]> >> wrote: >>> >>> I have finally hit upon the issue noted by Frank below and, indeed, I >>> could need a little help understanding the specification in this case. >>> >>> Here I am referring to test case: >>> >>> >>> https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f2/processor-tests/humans/substitute_SuppressOrdinaryVariable.txt >>> >>> When rendering the second item we have a book with an editor and a >>> title. Because there are no translators, the editor will be rendered >>> instead using the editor macro. But this macro is tricky. >>> >>> Since we have a book in this case, we could simplify it like this: >>> >>> <macro name="editor"> >>> <names variable="editor"> >>> <name/> >>> <label prefix=" " form="short"/> >>> </names> >>> <names variable="editor"> >>> <name/> >>> <label prefix=" "/> >>> </names> >>> </macro> >>> >>> Now, this presents three questions to me: >>> >>> First, how should we deal with names nodes (when used as substitutions) >>> that have child nodes? (If I am not mistaken this is the question to >>> which Frank wanted to alert us) — I do agree that this should be stated >>> explicitly in the spec. My initial approach was to not inherit anything >>> from the original names node, thinking that if style authors added a >>> node there specifically, it should always be used. But then I thought of >>> macros and realized that it is very likely that macros could be used in >>> substitutions and in this case I think it makes more sense for the >>> formatting of the nodes being substituted for always taking precedence. >>> I am undecided what makes more sense here, and just wanted to know what >>> the consesus is on this point? >>> >>> The second question I have is about the label node. The spec says this >>> in the Substitute section: >>> >>> "A shorthand version of cs:names without child elements, which inherits >>> the attributes values set on the cs:name and cs:et-al child elements of >>> the original cs:names element, may also be used." >>> >>> Does that mean that the label node is never inherited? >>> >>> But there is a third issue with this test case. When rendering Item-2 , >>> which is a book, the editor macro looks like the one I printed above >>> (unfolding the choose node and editor-short-label macro). >>> >>> citeproc-ruby renders this as "John-boy Doe ed.John-boy Doe editor." and >>> I can't say that I find any fault there. Here is what the spec says >>> about substitution and subsequent suppression: >>> >>> "If cs:substitute contains multiple child elements, the first element to >>> return a non-empty result is used for substitution. Substituted >>> variables are suppressed in the rest of the output to >>> prevent duplication." >>> >>> I have implemented it this way: when rendering substitutions, I start >>> rendering each child. Before the rendering starts, an observer object is >>> attached to the citation item that keeps track of all variables being >>> accessed. Now, if the child renders a non-empty result, this will be >>> used as the substiution. At this point can I mark all variables that >>> were used as suppressed (they are not deleted, but marked as suppressed, >>> so that conditional tests etc. still find the values, but at the same >>> time I can make sure they will not be printed again etc.). For this >>> reason, the output above makes a lot of sense to me. >>> >>> However, the expected test result is just: "John-boy Doe ed." — but this >>> does not seem right to me. The spec says, the first element to return a >>> non-empty result is used for substitution. In this case, this is the >>> editor macro which actually prints the editor twice! >>> >>> Obviously, this is a quite complicated example, so if I've made a >>> mistake, please do point me to it. In any case, I would be very >>> interested in your opinion on this, because as it stands I am reluctant >>> to change the way citeproc-ruby handles this. >>> >>> Thanks! >>> >>> Sylvester >>> >>> >>> >>> >>> >>> >>> >>> On Sat, 2012-09-08 at 18:03 +0900, Frank Bennett wrote: >>> > While looking into a error report from Sebastian, I found that >>> > citeproc-js was not coping gracefully with nested full-form cs:names >>> > nodes. >>> > >>> > While a cs:names node without children should inherit the labels from >>> > the preceding superior cs:name node on its parent, a full-form node >>> > should (I think) completely override all superior cs:label nodes. >>> > >>> > I suspect that other CSL implementations are likely to have cleaner >>> > internals than citeproc-js, and already behave in this way; but I >>> > thought I would mention it because I was a little surprised to find >>> > such a fundamental error in code that has been in service for so long. >>> > Here is a test that covers the issue: >>> > >>> > >>> > http://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f2/processor-tests/humans/substitute_SuppressOrdinaryVariable.txt >>> > >>> > (If I'm wrong and other implementations are tripped up on these nested >>> > structures, it might be worth mentioning the difference in behaviour >>> > explicitly in the specification.) >>> > >>> > Frank ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
