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
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University
------------------------------------------------------------------------------
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
