Group formatting

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Group formatting

Sylvester Keil
Here is another tricky one. From the spec:

"cs:group may carry the delimiter attribute to separate its child
elements, as well as affixes and display attributes (applied to the
output of the group as a whole) and formatting attributes (transmitted
to the enclosed elements)."

My interpretation of this was that each child node inherits the
formatting options of cs:group — that they apply to each child node
individually and not on the output of all the nodes as a whole.

But this test seems to contradict this:

https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f2/processor-tests/humans/sort_VariousNameMacros2.txt

The referenced style is:

https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f22c011b93a0deed3c9bf38efcec75/styles/journal-of-physiology-bib-sort-test-2.csl?at=default

And here I am interested in the "vol-page" macro:

<macro name="vol-page">
  <choose>
    <if variable="page">
      <group  prefix=" " suffix=" " font-weight="bold">
        <!--making group bold so that comma after volume is also bold-->
        <text variable="volume" suffix=","/>
      </group>
      <text variable="page"/>
    </if>
    <else>
      <text variable="DOI" prefix="; DOI: "/>
    </else>
  </choose>
</macro>

As you can see there is even a comment highlighting this very issue. The
results call for a result like "<b>3,</b>" like the comment suggests,
but I would have expected this to still render as "<b>3</b>," because of
the fact that the spec says a cs:group's formatting attributes are
transmitted to the enclosed elements.

I suspect my interpretation of 'transmitted to' is wrong; on the other
hand, the rendering implied by the test case seems like there is no
special treatment of cs:group formatting attributes, so why would this
be mentioned in the spec at all?

Thanks!

Sylvester






------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Group formatting

rmzelle
Administrator
On Sat, Jan 25, 2014 at 10:56 AM, Sylvester Keil <[hidden email]> wrote:

> Here is another tricky one. From the spec:
>
> "cs:group may carry the delimiter attribute to separate its child
> elements, as well as affixes and display attributes (applied to the
> output of the group as a whole) and formatting attributes (transmitted
> to the enclosed elements)."
>
> My interpretation of this was that each child node inherits the
> formatting options of cs:group — that they apply to each child node
> individually and not on the output of all the nodes as a whole.
>
> But this test seems to contradict this:
>
> https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f2/processor-tests/humans/sort_VariousNameMacros2.txt
>
> The referenced style is:
>
> https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f22c011b93a0deed3c9bf38efcec75/styles/journal-of-physiology-bib-sort-test-2.csl?at=default
>
> And here I am interested in the "vol-page" macro:
>
> <macro name="vol-page">
>   <choose>
>     <if variable="page">
>       <group  prefix=" " suffix=" " font-weight="bold">
>         <!--making group bold so that comma after volume is also bold-->
>         <text variable="volume" suffix=","/>
>       </group>
>       <text variable="page"/>
>     </if>
>     <else>
>       <text variable="DOI" prefix="; DOI: "/>
>     </else>
>   </choose>
> </macro>
>
> As you can see there is even a comment highlighting this very issue. The
> results call for a result like "<b>3,</b>" like the comment suggests,
> but I would have expected this to still render as "<b>3</b>," because of
> the fact that the spec says a cs:group's formatting attributes are
> transmitted to the enclosed elements.
>
> I suspect my interpretation of 'transmitted to' is wrong; on the other
> hand, the rendering implied by the test case seems like there is no
> special treatment of cs:group formatting attributes, so why would this
> be mentioned in the spec at all?

I'm pretty sure this has been discussed at some point, since the
language in the spec is rather specific, but I couldn't find that
discussion. Frank, do you know from the top of your head?

Rintze

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: Group formatting

fbennett
Sorry for replying so late. I've stumbled across the thread while looking for something else.

"Transmitted" must mean what Sylvester assumes that it means, but that's obviously not what the test require. I think that clause should just be removed from the spec.

At some point I may have thought that italics etc. should be set exclusively on the rendering elements, but as far as I can tell (thinking about it now) the only effect of that would have been to reduce flexibility.

Frank




On Mon, Jan 27, 2014 at 3:53 AM, Rintze Zelle <[hidden email]> wrote:
On Sat, Jan 25, 2014 at 10:56 AM, Sylvester Keil <[hidden email]> wrote:
> Here is another tricky one. From the spec:
>
> "cs:group may carry the delimiter attribute to separate its child
> elements, as well as affixes and display attributes (applied to the
> output of the group as a whole) and formatting attributes (transmitted
> to the enclosed elements)."
>
> My interpretation of this was that each child node inherits the
> formatting options of cs:group — that they apply to each child node
> individually and not on the output of all the nodes as a whole.
>
> But this test seems to contradict this:
>
> https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f2/processor-tests/humans/sort_VariousNameMacros2.txt
>
> The referenced style is:
>
> https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f22c011b93a0deed3c9bf38efcec75/styles/journal-of-physiology-bib-sort-test-2.csl?at=default
>
> And here I am interested in the "vol-page" macro:
>
> <macro name="vol-page">
>   <choose>
>     <if variable="page">
>       <group  prefix=" " suffix=" " font-weight="bold">
>         <!--making group bold so that comma after volume is also bold-->
>         <text variable="volume" suffix=","/>
>       </group>
>       <text variable="page"/>
>     </if>
>     <else>
>       <text variable="DOI" prefix="; DOI: "/>
>     </else>
>   </choose>
> </macro>
>
> As you can see there is even a comment highlighting this very issue. The
> results call for a result like "<b>3,</b>" like the comment suggests,
> but I would have expected this to still render as "<b>3</b>," because of
> the fact that the spec says a cs:group's formatting attributes are
> transmitted to the enclosed elements.
>
> I suspect my interpretation of 'transmitted to' is wrong; on the other
> hand, the rendering implied by the test case seems like there is no
> special treatment of cs:group formatting attributes, so why would this
> be mentioned in the spec at all?

I'm pretty sure this has been discussed at some point, since the
language in the spec is rather specific, but I couldn't find that
discussion. Frank, do you know from the top of your head?

Rintze

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: Group formatting

Sebastian Karcher
huh - missed this, too. I agree with Frank. We want to keep the
current behavior of citeproc-js and fix the specs.

On Thu, Jul 3, 2014 at 4:46 PM, Frank Bennett <[hidden email]> wrote:

> Sorry for replying so late. I've stumbled across the thread while looking
> for something else.
>
> "Transmitted" must mean what Sylvester assumes that it means, but that's
> obviously not what the test require. I think that clause should just be
> removed from the spec.
>
> At some point I may have thought that italics etc. should be set exclusively
> on the rendering elements, but as far as I can tell (thinking about it now)
> the only effect of that would have been to reduce flexibility.
>
> Frank
>
>
>
>
> On Mon, Jan 27, 2014 at 3:53 AM, Rintze Zelle <[hidden email]>
> wrote:
>>
>> On Sat, Jan 25, 2014 at 10:56 AM, Sylvester Keil <[hidden email]>
>> wrote:
>> > Here is another tricky one. From the spec:
>> >
>> > "cs:group may carry the delimiter attribute to separate its child
>> > elements, as well as affixes and display attributes (applied to the
>> > output of the group as a whole) and formatting attributes (transmitted
>> > to the enclosed elements)."
>> >
>> > My interpretation of this was that each child node inherits the
>> > formatting options of cs:group — that they apply to each child node
>> > individually and not on the output of all the nodes as a whole.
>> >
>> > But this test seems to contradict this:
>> >
>> >
>> > https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f2/processor-tests/humans/sort_VariousNameMacros2.txt
>> >
>> > The referenced style is:
>> >
>> >
>> > https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f22c011b93a0deed3c9bf38efcec75/styles/journal-of-physiology-bib-sort-test-2.csl?at=default
>> >
>> > And here I am interested in the "vol-page" macro:
>> >
>> > <macro name="vol-page">
>> >   <choose>
>> >     <if variable="page">
>> >       <group  prefix=" " suffix=" " font-weight="bold">
>> >         <!--making group bold so that comma after volume is also bold-->
>> >         <text variable="volume" suffix=","/>
>> >       </group>
>> >       <text variable="page"/>
>> >     </if>
>> >     <else>
>> >       <text variable="DOI" prefix="; DOI: "/>
>> >     </else>
>> >   </choose>
>> > </macro>
>> >
>> > As you can see there is even a comment highlighting this very issue. The
>> > results call for a result like "<b>3,</b>" like the comment suggests,
>> > but I would have expected this to still render as "<b>3</b>," because of
>> > the fact that the spec says a cs:group's formatting attributes are
>> > transmitted to the enclosed elements.
>> >
>> > I suspect my interpretation of 'transmitted to' is wrong; on the other
>> > hand, the rendering implied by the test case seems like there is no
>> > special treatment of cs:group formatting attributes, so why would this
>> > be mentioned in the spec at all?
>>
>> I'm pretty sure this has been discussed at some point, since the
>> language in the spec is rather specific, but I couldn't find that
>> discussion. Frank, do you know from the top of your head?
>>
>> Rintze
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>



--
Sebastian Karcher, PhD
Department of Political Science
Northwestern University

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: Group formatting

Sylvester Keil
Thanks for the clarification! I think Frank is completely right that
this actually reduces flexibility, especially in the context of macros.
I'll remove the 'feature' from citeproc-ruby, too.

Sylvester

On Fri, 2014-07-04 at 18:04 -0600, Sebastian Karcher wrote:

> huh - missed this, too. I agree with Frank. We want to keep the
> current behavior of citeproc-js and fix the specs.
>
> On Thu, Jul 3, 2014 at 4:46 PM, Frank Bennett <[hidden email]> wrote:
> > Sorry for replying so late. I've stumbled across the thread while looking
> > for something else.
> >
> > "Transmitted" must mean what Sylvester assumes that it means, but that's
> > obviously not what the test require. I think that clause should just be
> > removed from the spec.
> >
> > At some point I may have thought that italics etc. should be set exclusively
> > on the rendering elements, but as far as I can tell (thinking about it now)
> > the only effect of that would have been to reduce flexibility.
> >
> > Frank
> >
> >
> >
> >
> > On Mon, Jan 27, 2014 at 3:53 AM, Rintze Zelle <[hidden email]>
> > wrote:
> >>
> >> On Sat, Jan 25, 2014 at 10:56 AM, Sylvester Keil <[hidden email]>
> >> wrote:
> >> > Here is another tricky one. From the spec:
> >> >
> >> > "cs:group may carry the delimiter attribute to separate its child
> >> > elements, as well as affixes and display attributes (applied to the
> >> > output of the group as a whole) and formatting attributes (transmitted
> >> > to the enclosed elements)."
> >> >
> >> > My interpretation of this was that each child node inherits the
> >> > formatting options of cs:group — that they apply to each child node
> >> > individually and not on the output of all the nodes as a whole.
> >> >
> >> > But this test seems to contradict this:
> >> >
> >> >
> >> > https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f2/processor-tests/humans/sort_VariousNameMacros2.txt
> >> >
> >> > The referenced style is:
> >> >
> >> >
> >> > https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f22c011b93a0deed3c9bf38efcec75/styles/journal-of-physiology-bib-sort-test-2.csl?at=default
> >> >
> >> > And here I am interested in the "vol-page" macro:
> >> >
> >> > <macro name="vol-page">
> >> >   <choose>
> >> >     <if variable="page">
> >> >       <group  prefix=" " suffix=" " font-weight="bold">
> >> >         <!--making group bold so that comma after volume is also bold-->
> >> >         <text variable="volume" suffix=","/>
> >> >       </group>
> >> >       <text variable="page"/>
> >> >     </if>
> >> >     <else>
> >> >       <text variable="DOI" prefix="; DOI: "/>
> >> >     </else>
> >> >   </choose>
> >> > </macro>
> >> >
> >> > As you can see there is even a comment highlighting this very issue. The
> >> > results call for a result like "<b>3,</b>" like the comment suggests,
> >> > but I would have expected this to still render as "<b>3</b>," because of
> >> > the fact that the spec says a cs:group's formatting attributes are
> >> > transmitted to the enclosed elements.
> >> >
> >> > I suspect my interpretation of 'transmitted to' is wrong; on the other
> >> > hand, the rendering implied by the test case seems like there is no
> >> > special treatment of cs:group formatting attributes, so why would this
> >> > be mentioned in the spec at all?
> >>
> >> I'm pretty sure this has been discussed at some point, since the
> >> language in the spec is rather specific, but I couldn't find that
> >> discussion. Frank, do you know from the top of your head?
> >>
> >> Rintze
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> 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
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > xbiblio-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
> >
>
>
>

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Group formatting

Sylvester Keil
FYI I just created a pull request for this:

https://github.com/citation-style-language/documentation/pull/34

This would assume that formatting attributes are still valid (this also means there should be no change to the schema necessary) and applied to the group as a whole (I assume this is how citeproc-js would treat the situation now?).

Sylvester

On Jul 5, 2014, at 1:29 PM, Sylvester Keil <[hidden email]> wrote:

> Thanks for the clarification! I think Frank is completely right that
> this actually reduces flexibility, especially in the context of macros.
> I'll remove the 'feature' from citeproc-ruby, too.
>
> Sylvester
>
> On Fri, 2014-07-04 at 18:04 -0600, Sebastian Karcher wrote:
>> huh - missed this, too. I agree with Frank. We want to keep the
>> current behavior of citeproc-js and fix the specs.
>>
>> On Thu, Jul 3, 2014 at 4:46 PM, Frank Bennett <[hidden email]> wrote:
>>> Sorry for replying so late. I've stumbled across the thread while looking
>>> for something else.
>>>
>>> "Transmitted" must mean what Sylvester assumes that it means, but that's
>>> obviously not what the test require. I think that clause should just be
>>> removed from the spec.
>>>
>>> At some point I may have thought that italics etc. should be set exclusively
>>> on the rendering elements, but as far as I can tell (thinking about it now)
>>> the only effect of that would have been to reduce flexibility.
>>>
>>> Frank
>>>
>>>
>>>
>>>
>>> On Mon, Jan 27, 2014 at 3:53 AM, Rintze Zelle <[hidden email]>
>>> wrote:
>>>>
>>>> On Sat, Jan 25, 2014 at 10:56 AM, Sylvester Keil <[hidden email]>
>>>> wrote:
>>>>> Here is another tricky one. From the spec:
>>>>>
>>>>> "cs:group may carry the delimiter attribute to separate its child
>>>>> elements, as well as affixes and display attributes (applied to the
>>>>> output of the group as a whole) and formatting attributes (transmitted
>>>>> to the enclosed elements)."
>>>>>
>>>>> My interpretation of this was that each child node inherits the
>>>>> formatting options of cs:group — that they apply to each child node
>>>>> individually and not on the output of all the nodes as a whole.
>>>>>
>>>>> But this test seems to contradict this:
>>>>>
>>>>>
>>>>> https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f2/processor-tests/humans/sort_VariousNameMacros2.txt
>>>>>
>>>>> The referenced style is:
>>>>>
>>>>>
>>>>> https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f22c011b93a0deed3c9bf38efcec75/styles/journal-of-physiology-bib-sort-test-2.csl?at=default
>>>>>
>>>>> And here I am interested in the "vol-page" macro:
>>>>>
>>>>> <macro name="vol-page">
>>>>>  <choose>
>>>>>    <if variable="page">
>>>>>      <group  prefix=" " suffix=" " font-weight="bold">
>>>>>        <!--making group bold so that comma after volume is also bold-->
>>>>>        <text variable="volume" suffix=","/>
>>>>>      </group>
>>>>>      <text variable="page"/>
>>>>>    </if>
>>>>>    <else>
>>>>>      <text variable="DOI" prefix="; DOI: "/>
>>>>>    </else>
>>>>>  </choose>
>>>>> </macro>
>>>>>
>>>>> As you can see there is even a comment highlighting this very issue. The
>>>>> results call for a result like "<b>3,</b>" like the comment suggests,
>>>>> but I would have expected this to still render as "<b>3</b>," because of
>>>>> the fact that the spec says a cs:group's formatting attributes are
>>>>> transmitted to the enclosed elements.
>>>>>
>>>>> I suspect my interpretation of 'transmitted to' is wrong; on the other
>>>>> hand, the rendering implied by the test case seems like there is no
>>>>> special treatment of cs:group formatting attributes, so why would this
>>>>> be mentioned in the spec at all?
>>>>
>>>> I'm pretty sure this has been discussed at some point, since the
>>>> language in the spec is rather specific, but I couldn't find that
>>>> discussion. Frank, do you know from the top of your head?
>>>>
>>>> Rintze
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Open source business process management suite built on Java and Eclipse
>>> Turn processes into business applications with Bonita BPM Community Edition
>>> Quickly connect people, data, and systems into organized workflows
>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> http://p.sf.net/sfu/Bonitasoft
>>> _______________________________________________
>>> xbiblio-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>>>
>>
>>
>>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft_______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Group formatting

rmzelle
Administrator
Looks good to me.

Rintze

On Mon, Jul 7, 2014 at 5:27 PM, Sylvester Keil <[hidden email]> wrote:

> FYI I just created a pull request for this:
>
> https://github.com/citation-style-language/documentation/pull/34
>
> This would assume that formatting attributes are still valid (this also means there should be no change to the schema necessary) and applied to the group as a whole (I assume this is how citeproc-js would treat the situation now?).
>
> Sylvester
>
> On Jul 5, 2014, at 1:29 PM, Sylvester Keil <[hidden email]> wrote:
>
>> Thanks for the clarification! I think Frank is completely right that
>> this actually reduces flexibility, especially in the context of macros.
>> I'll remove the 'feature' from citeproc-ruby, too.
>>
>> Sylvester
>>
>> On Fri, 2014-07-04 at 18:04 -0600, Sebastian Karcher wrote:
>>> huh - missed this, too. I agree with Frank. We want to keep the
>>> current behavior of citeproc-js and fix the specs.
>>>
>>> On Thu, Jul 3, 2014 at 4:46 PM, Frank Bennett <[hidden email]> wrote:
>>>> Sorry for replying so late. I've stumbled across the thread while looking
>>>> for something else.
>>>>
>>>> "Transmitted" must mean what Sylvester assumes that it means, but that's
>>>> obviously not what the test require. I think that clause should just be
>>>> removed from the spec.
>>>>
>>>> At some point I may have thought that italics etc. should be set exclusively
>>>> on the rendering elements, but as far as I can tell (thinking about it now)
>>>> the only effect of that would have been to reduce flexibility.
>>>>
>>>> Frank
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jan 27, 2014 at 3:53 AM, Rintze Zelle <[hidden email]>
>>>> wrote:
>>>>>
>>>>> On Sat, Jan 25, 2014 at 10:56 AM, Sylvester Keil <[hidden email]>
>>>>> wrote:
>>>>>> Here is another tricky one. From the spec:
>>>>>>
>>>>>> "cs:group may carry the delimiter attribute to separate its child
>>>>>> elements, as well as affixes and display attributes (applied to the
>>>>>> output of the group as a whole) and formatting attributes (transmitted
>>>>>> to the enclosed elements)."
>>>>>>
>>>>>> My interpretation of this was that each child node inherits the
>>>>>> formatting options of cs:group — that they apply to each child node
>>>>>> individually and not on the output of all the nodes as a whole.
>>>>>>
>>>>>> But this test seems to contradict this:
>>>>>>
>>>>>>
>>>>>> https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f2/processor-tests/humans/sort_VariousNameMacros2.txt
>>>>>>
>>>>>> The referenced style is:
>>>>>>
>>>>>>
>>>>>> https://bitbucket.org/bdarcus/citeproc-test/src/ab136a6aa8f22c011b93a0deed3c9bf38efcec75/styles/journal-of-physiology-bib-sort-test-2.csl?at=default
>>>>>>
>>>>>> And here I am interested in the "vol-page" macro:
>>>>>>
>>>>>> <macro name="vol-page">
>>>>>>  <choose>
>>>>>>    <if variable="page">
>>>>>>      <group  prefix=" " suffix=" " font-weight="bold">
>>>>>>        <!--making group bold so that comma after volume is also bold-->
>>>>>>        <text variable="volume" suffix=","/>
>>>>>>      </group>
>>>>>>      <text variable="page"/>
>>>>>>    </if>
>>>>>>    <else>
>>>>>>      <text variable="DOI" prefix="; DOI: "/>
>>>>>>    </else>
>>>>>>  </choose>
>>>>>> </macro>
>>>>>>
>>>>>> As you can see there is even a comment highlighting this very issue. The
>>>>>> results call for a result like "<b>3,</b>" like the comment suggests,
>>>>>> but I would have expected this to still render as "<b>3</b>," because of
>>>>>> the fact that the spec says a cs:group's formatting attributes are
>>>>>> transmitted to the enclosed elements.
>>>>>>
>>>>>> I suspect my interpretation of 'transmitted to' is wrong; on the other
>>>>>> hand, the rendering implied by the test case seems like there is no
>>>>>> special treatment of cs:group formatting attributes, so why would this
>>>>>> be mentioned in the spec at all?
>>>>>
>>>>> I'm pretty sure this has been discussed at some point, since the
>>>>> language in the spec is rather specific, but I couldn't find that
>>>>> discussion. Frank, do you know from the top of your head?
>>>>>
>>>>> Rintze
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Open source business process management suite built on Java and Eclipse
>>>> Turn processes into business applications with Bonita BPM Community Edition
>>>> Quickly connect people, data, and systems into organized workflows
>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>> http://p.sf.net/sfu/Bonitasoft
>>>> _______________________________________________
>>>> xbiblio-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>>>>
>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft_______________________________________________
>> xbiblio-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel