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 > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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
