cs:group

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

cs:group

Ron Jerome
Hi Folks,

I've run into an issue with cs:group elements and seek some clarification on the spec.

I have a group which contains a number of elements rendered either directly from variables for indirectly from macros. 

My interpretation of the spec is that ALL of the variables/macros have to be empty before the group is suppressed, but in the case of a group with multiple variables/macros, this can produce some strange output. 

Here is my specific case...

        <group delimiter="">
          <text term="in" suffix=": " text-case="capitalize-first"/>
          <text macro="container-contributors" prefix=" " suffix=": "/>
          <text macro="container-title" suffix="."/>
          <label variable="page" form="short" text-case="lowercase" suffix=". " prefix="  &#8211; "/>
          <text variable="page" suffix=","/>
        </group>

In this case, both "container-contributors" and "container-title" macros evaluate empty but the "page" variable is there, so it creates strange output like this...

"In:   – pp. 329–368"

Seems to me in this case, the whole thing should be suppressed. 

Am I misinterpreting the spec?

Ron.

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: cs:group

Bruce D'Arcus-3
Without getting too deep, step back a bit and note that the data in
this case is flawed.

The purpose of that group is to describe the characteristics of a
container; likely a book. If the data record doesn't have a title or
contributor (editor), then you can't get a correct formatted
reference.

So in short, a bug in the data.

Bruce

On Sat, Dec 8, 2012 at 2:18 PM, Ron Jerome <[hidden email]> wrote:

> Hi Folks,
>
> I've run into an issue with cs:group elements and seek some clarification on
> the spec.
>
> I have a group which contains a number of elements rendered either directly
> from variables for indirectly from macros.
>
> My interpretation of the spec is that ALL of the variables/macros have to be
> empty before the group is suppressed, but in the case of a group with
> multiple variables/macros, this can produce some strange output.
>
> Here is my specific case...
>
>         <group delimiter="">
>           <text term="in" suffix=": " text-case="capitalize-first"/>
>           <text macro="container-contributors" prefix=" " suffix=": "/>
>           <text macro="container-title" suffix="."/>
>           <label variable="page" form="short" text-case="lowercase"
> suffix=". " prefix="  &#8211; "/>
>           <text variable="page" suffix=","/>
>         </group>
>
> In this case, both "container-contributors" and "container-title" macros
> evaluate empty but the "page" variable is there, so it creates strange
> output like this...
>
> "In:   – pp. 329–368"
>
> Seems to me in this case, the whole thing should be suppressed.
>
> Am I misinterpreting the spec?
>
> Ron.
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: cs:group

Sebastian Karcher
also, look at the spec again:
a group is suppressed if:
a) at least one rendering element in cs:group calls a variable (either directly or via a macro), and b) all variables that are called are empty. This accommodates descriptive cs:text elements.

b) is not the case in your example, as page is a variable and it's not empty. So this is exactly what the specs are saying.

Bruce is right, of course, that the data is faulty in your example, but one of the nice thing about groups is that they help you deal with incomplete data - in this case probably something like (also cleaning up some of the remaining code):
    <group delimiter=": " suffix=".">
          <text term="in" text-case="capitalize-first"/>
          <text macro="container-contributors"/>
          <text macro="container-title"/>
 </group>
<group>
          <label variable="page" form="short" prefix="  &#8211; "/>
          <text variable="page" suffix=","/>
        </group>




On Sat, Dec 8, 2012 at 12:24 PM, Bruce D'Arcus <[hidden email]> wrote:
Without getting too deep, step back a bit and note that the data in
this case is flawed.

The purpose of that group is to describe the characteristics of a
container; likely a book. If the data record doesn't have a title or
contributor (editor), then you can't get a correct formatted
reference.

So in short, a bug in the data.

Bruce

On Sat, Dec 8, 2012 at 2:18 PM, Ron Jerome <[hidden email]> wrote:
> Hi Folks,
>
> I've run into an issue with cs:group elements and seek some clarification on
> the spec.
>
> I have a group which contains a number of elements rendered either directly
> from variables for indirectly from macros.
>
> My interpretation of the spec is that ALL of the variables/macros have to be
> empty before the group is suppressed, but in the case of a group with
> multiple variables/macros, this can produce some strange output.
>
> Here is my specific case...
>
>         <group delimiter="">
>           <text term="in" suffix=": " text-case="capitalize-first"/>
>           <text macro="container-contributors" prefix=" " suffix=": "/>
>           <text macro="container-title" suffix="."/>
>           <label variable="page" form="short" text-case="lowercase"
> suffix=". " prefix="  &#8211; "/>
>           <text variable="page" suffix=","/>
>         </group>
>
> In this case, both "container-contributors" and "container-title" macros
> evaluate empty but the "page" variable is there, so it creates strange
> output like this...
>
> "In:   – pp. 329–368"
>
> Seems to me in this case, the whole thing should be suppressed.
>
> Am I misinterpreting the spec?
>
> Ron.
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: cs:group

Ron Jerome
Hi Bruce & Sebastian

You are correct on both counts, it is a book descriptor, and it is flawed data.

But I guess my question is that if a cs:group is going to act like a conditional, shouldn't ALL the variables/macros be required to evaluate to TRUE, not just one? Allowing output with ANY variable/macro evaluating to TRUE can lead to incorrect output as we see here. Or, perhaps there could be a "match" attribute attached to the group to control this behavior.

In this case I don't want any output, regardless of the fact that I do have a "page" variable.

Ron.


On Sat, Dec 8, 2012 at 2:30 PM, Sebastian Karcher <[hidden email]> wrote:
also, look at the spec again:
a group is suppressed if:
a) at least one rendering element in cs:group calls a variable (either directly or via a macro), and b) all variables that are called are empty. This accommodates descriptive cs:text elements.

b) is not the case in your example, as page is a variable and it's not empty. So this is exactly what the specs are saying.

Bruce is right, of course, that the data is faulty in your example, but one of the nice thing about groups is that they help you deal with incomplete data - in this case probably something like (also cleaning up some of the remaining code):
    <group delimiter=": " suffix=".">
          <text term="in" text-case="capitalize-first"/>
          <text macro="container-contributors"/>
          <text macro="container-title"/>
 </group>
<group>
          <label variable="page" form="short" prefix="  &#8211; "/>

          <text variable="page" suffix=","/>
        </group>




On Sat, Dec 8, 2012 at 12:24 PM, Bruce D'Arcus <[hidden email]> wrote:
Without getting too deep, step back a bit and note that the data in
this case is flawed.

The purpose of that group is to describe the characteristics of a
container; likely a book. If the data record doesn't have a title or
contributor (editor), then you can't get a correct formatted
reference.

So in short, a bug in the data.

Bruce

On Sat, Dec 8, 2012 at 2:18 PM, Ron Jerome <[hidden email]> wrote:
> Hi Folks,
>
> I've run into an issue with cs:group elements and seek some clarification on
> the spec.
>
> I have a group which contains a number of elements rendered either directly
> from variables for indirectly from macros.
>
> My interpretation of the spec is that ALL of the variables/macros have to be
> empty before the group is suppressed, but in the case of a group with
> multiple variables/macros, this can produce some strange output.
>
> Here is my specific case...
>
>         <group delimiter="">
>           <text term="in" suffix=": " text-case="capitalize-first"/>
>           <text macro="container-contributors" prefix=" " suffix=": "/>
>           <text macro="container-title" suffix="."/>
>           <label variable="page" form="short" text-case="lowercase"
> suffix=". " prefix="  &#8211; "/>
>           <text variable="page" suffix=","/>
>         </group>
>
> In this case, both "container-contributors" and "container-title" macros
> evaluate empty but the "page" variable is there, so it creates strange
> output like this...
>
> "In:   – pp. 329–368"
>
> Seems to me in this case, the whole thing should be suppressed.
>
> Am I misinterpreting the spec?
>
> Ron.
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: cs:group

Sebastian Karcher

But I guess my question is that if a cs:group is going to act like a conditional, shouldn't ALL the variables/macros be required to evaluate to TRUE, not just one? Allowing output with ANY variable/macro evaluating to TRUE can lead to incorrect output as we see here. Or, perhaps there could be a "match" attribute attached to the group to control this behavior.
 
no, most definitely not! The most important purpose of groups is that they deal correctly with missing values. A typical case is e.g. "edition," which only exists for some book. We'd often do something like:
<group delimiter=", " suffix=".">
<text variable="title">
<text macro="edition"/>
</group>

Which produces:
Book Title.   (when there is no edition)
and
Book Title, 2nd edition. (when there is no edition)
That's what groups are for - it would obviously be bad if this entire group disappeared where there is no edition.
The reason you're getting wrong output in your example is that you're using groups wrong. See my example code in the prior e-mail for a better way of doing this.

I see no reason for changing the current behavior, which works great. It's always going to be possible to create faulty output if you write syntax that doesn't take into account the specs properly.

Sebastian
 

In this case I don't want any output, regardless of the fact that I do have a "page" variable.

Ron.


On Sat, Dec 8, 2012 at 2:30 PM, Sebastian Karcher <[hidden email]> wrote:
also, look at the spec again:
a group is suppressed if:
a) at least one rendering element in cs:group calls a variable (either directly or via a macro), and b) all variables that are called are empty. This accommodates descriptive cs:text elements.

b) is not the case in your example, as page is a variable and it's not empty. So this is exactly what the specs are saying.

Bruce is right, of course, that the data is faulty in your example, but one of the nice thing about groups is that they help you deal with incomplete data - in this case probably something like (also cleaning up some of the remaining code):
    <group delimiter=": " suffix=".">
          <text term="in" text-case="capitalize-first"/>
          <text macro="container-contributors"/>
          <text macro="container-title"/>
 </group>
<group>
          <label variable="page" form="short" prefix="  &#8211; "/>

          <text variable="page" suffix=","/>
        </group>




On Sat, Dec 8, 2012 at 12:24 PM, Bruce D'Arcus <[hidden email]> wrote:
Without getting too deep, step back a bit and note that the data in
this case is flawed.

The purpose of that group is to describe the characteristics of a
container; likely a book. If the data record doesn't have a title or
contributor (editor), then you can't get a correct formatted
reference.

So in short, a bug in the data.

Bruce

On Sat, Dec 8, 2012 at 2:18 PM, Ron Jerome <[hidden email]> wrote:
> Hi Folks,
>
> I've run into an issue with cs:group elements and seek some clarification on
> the spec.
>
> I have a group which contains a number of elements rendered either directly
> from variables for indirectly from macros.
>
> My interpretation of the spec is that ALL of the variables/macros have to be
> empty before the group is suppressed, but in the case of a group with
> multiple variables/macros, this can produce some strange output.
>
> Here is my specific case...
>
>         <group delimiter="">
>           <text term="in" suffix=": " text-case="capitalize-first"/>
>           <text macro="container-contributors" prefix=" " suffix=": "/>
>           <text macro="container-title" suffix="."/>
>           <label variable="page" form="short" text-case="lowercase"
> suffix=". " prefix="  &#8211; "/>
>           <text variable="page" suffix=","/>
>         </group>
>
> In this case, both "container-contributors" and "container-title" macros
> evaluate empty but the "page" variable is there, so it creates strange
> output like this...
>
> "In:   – pp. 329–368"
>
> Seems to me in this case, the whole thing should be suppressed.
>
> Am I misinterpreting the spec?
>
> Ron.
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel




--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University


On Sat, Dec 8, 2012 at 1:27 PM, Ron Jerome <[hidden email]> wrote:
Hi Bruce & Sebastian

You are correct on both counts, it is a book descriptor, and it is flawed data.

But I guess my question is that if a cs:group is going to act like a conditional, shouldn't ALL the variables/macros be required to evaluate to TRUE, not just one? Allowing output with ANY variable/macro evaluating to TRUE can lead to incorrect output as we see here. Or, perhaps there could be a "match" attribute attached to the group to control this behavior.

In this case I don't want any output, regardless of the fact that I do have a "page" variable.

Ron.


On Sat, Dec 8, 2012 at 2:30 PM, Sebastian Karcher <[hidden email]> wrote:
also, look at the spec again:
a group is suppressed if:
a) at least one rendering element in cs:group calls a variable (either directly or via a macro), and b) all variables that are called are empty. This accommodates descriptive cs:text elements.

b) is not the case in your example, as page is a variable and it's not empty. So this is exactly what the specs are saying.

Bruce is right, of course, that the data is faulty in your example, but one of the nice thing about groups is that they help you deal with incomplete data - in this case probably something like (also cleaning up some of the remaining code):
    <group delimiter=": " suffix=".">
          <text term="in" text-case="capitalize-first"/>
          <text macro="container-contributors"/>
          <text macro="container-title"/>
 </group>
<group>
          <label variable="page" form="short" prefix="  &#8211; "/>

          <text variable="page" suffix=","/>
        </group>




On Sat, Dec 8, 2012 at 12:24 PM, Bruce D'Arcus <[hidden email]> wrote:
Without getting too deep, step back a bit and note that the data in
this case is flawed.

The purpose of that group is to describe the characteristics of a
container; likely a book. If the data record doesn't have a title or
contributor (editor), then you can't get a correct formatted
reference.

So in short, a bug in the data.

Bruce

On Sat, Dec 8, 2012 at 2:18 PM, Ron Jerome <[hidden email]> wrote:
> Hi Folks,
>
> I've run into an issue with cs:group elements and seek some clarification on
> the spec.
>
> I have a group which contains a number of elements rendered either directly
> from variables for indirectly from macros.
>
> My interpretation of the spec is that ALL of the variables/macros have to be
> empty before the group is suppressed, but in the case of a group with
> multiple variables/macros, this can produce some strange output.
>
> Here is my specific case...
>
>         <group delimiter="">
>           <text term="in" suffix=": " text-case="capitalize-first"/>
>           <text macro="container-contributors" prefix=" " suffix=": "/>
>           <text macro="container-title" suffix="."/>
>           <label variable="page" form="short" text-case="lowercase"
> suffix=". " prefix="  &#8211; "/>
>           <text variable="page" suffix=","/>
>         </group>
>
> In this case, both "container-contributors" and "container-title" macros
> evaluate empty but the "page" variable is there, so it creates strange
> output like this...
>
> "In:   – pp. 329–368"
>
> Seems to me in this case, the whole thing should be suppressed.
>
> Am I misinterpreting the spec?
>
> Ron.
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel




--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
Reply | Threaded
Open this post in threaded view
|

Re: cs:group

Ron Jerome
OK, fair enough.  I just wanted to make sure that my csl processor (citeproc-php) was doing what it was supposed to.  Now I can point the finger at the CSL author :-)

Cheers,

Ron.


On Sat, Dec 8, 2012 at 3:38 PM, Sebastian Karcher <[hidden email]> wrote:

But I guess my question is that if a cs:group is going to act like a conditional, shouldn't ALL the variables/macros be required to evaluate to TRUE, not just one? Allowing output with ANY variable/macro evaluating to TRUE can lead to incorrect output as we see here. Or, perhaps there could be a "match" attribute attached to the group to control this behavior.
 
no, most definitely not! The most important purpose of groups is that they deal correctly with missing values. A typical case is e.g. "edition," which only exists for some book. We'd often do something like:
<group delimiter=", " suffix=".">
<text variable="title">
<text macro="edition"/>
</group>

Which produces:
Book Title.   (when there is no edition)
and
Book Title, 2nd edition. (when there is no edition)
That's what groups are for - it would obviously be bad if this entire group disappeared where there is no edition.
The reason you're getting wrong output in your example is that you're using groups wrong. See my example code in the prior e-mail for a better way of doing this.

I see no reason for changing the current behavior, which works great. It's always going to be possible to create faulty output if you write syntax that doesn't take into account the specs properly.

Sebastian
 

In this case I don't want any output, regardless of the fact that I do have a "page" variable.

Ron.


On Sat, Dec 8, 2012 at 2:30 PM, Sebastian Karcher <[hidden email]> wrote:
also, look at the spec again:
a group is suppressed if:
a) at least one rendering element in cs:group calls a variable (either directly or via a macro), and b) all variables that are called are empty. This accommodates descriptive cs:text elements.

b) is not the case in your example, as page is a variable and it's not empty. So this is exactly what the specs are saying.

Bruce is right, of course, that the data is faulty in your example, but one of the nice thing about groups is that they help you deal with incomplete data - in this case probably something like (also cleaning up some of the remaining code):
    <group delimiter=": " suffix=".">
          <text term="in" text-case="capitalize-first"/>
          <text macro="container-contributors"/>
          <text macro="container-title"/>
 </group>
<group>
          <label variable="page" form="short" prefix="  &#8211; "/>

          <text variable="page" suffix=","/>
        </group>




On Sat, Dec 8, 2012 at 12:24 PM, Bruce D'Arcus <[hidden email]> wrote:
Without getting too deep, step back a bit and note that the data in
this case is flawed.

The purpose of that group is to describe the characteristics of a
container; likely a book. If the data record doesn't have a title or
contributor (editor), then you can't get a correct formatted
reference.

So in short, a bug in the data.

Bruce

On Sat, Dec 8, 2012 at 2:18 PM, Ron Jerome <[hidden email]> wrote:
> Hi Folks,
>
> I've run into an issue with cs:group elements and seek some clarification on
> the spec.
>
> I have a group which contains a number of elements rendered either directly
> from variables for indirectly from macros.
>
> My interpretation of the spec is that ALL of the variables/macros have to be
> empty before the group is suppressed, but in the case of a group with
> multiple variables/macros, this can produce some strange output.
>
> Here is my specific case...
>
>         <group delimiter="">
>           <text term="in" suffix=": " text-case="capitalize-first"/>
>           <text macro="container-contributors" prefix=" " suffix=": "/>
>           <text macro="container-title" suffix="."/>
>           <label variable="page" form="short" text-case="lowercase"
> suffix=". " prefix="  &#8211; "/>
>           <text variable="page" suffix=","/>
>         </group>
>
> In this case, both "container-contributors" and "container-title" macros
> evaluate empty but the "page" variable is there, so it creates strange
> output like this...
>
> "In:   – pp. 329–368"
>
> Seems to me in this case, the whole thing should be suppressed.
>
> Am I misinterpreting the spec?
>
> Ron.
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel




--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University


On Sat, Dec 8, 2012 at 1:27 PM, Ron Jerome <[hidden email]> wrote:
Hi Bruce & Sebastian

You are correct on both counts, it is a book descriptor, and it is flawed data.

But I guess my question is that if a cs:group is going to act like a conditional, shouldn't ALL the variables/macros be required to evaluate to TRUE, not just one? Allowing output with ANY variable/macro evaluating to TRUE can lead to incorrect output as we see here. Or, perhaps there could be a "match" attribute attached to the group to control this behavior.

In this case I don't want any output, regardless of the fact that I do have a "page" variable.

Ron.


On Sat, Dec 8, 2012 at 2:30 PM, Sebastian Karcher <[hidden email]> wrote:
also, look at the spec again:
a group is suppressed if:
a) at least one rendering element in cs:group calls a variable (either directly or via a macro), and b) all variables that are called are empty. This accommodates descriptive cs:text elements.

b) is not the case in your example, as page is a variable and it's not empty. So this is exactly what the specs are saying.

Bruce is right, of course, that the data is faulty in your example, but one of the nice thing about groups is that they help you deal with incomplete data - in this case probably something like (also cleaning up some of the remaining code):
    <group delimiter=": " suffix=".">
          <text term="in" text-case="capitalize-first"/>
          <text macro="container-contributors"/>
          <text macro="container-title"/>
 </group>
<group>
          <label variable="page" form="short" prefix="  &#8211; "/>

          <text variable="page" suffix=","/>
        </group>




On Sat, Dec 8, 2012 at 12:24 PM, Bruce D'Arcus <[hidden email]> wrote:
Without getting too deep, step back a bit and note that the data in
this case is flawed.

The purpose of that group is to describe the characteristics of a
container; likely a book. If the data record doesn't have a title or
contributor (editor), then you can't get a correct formatted
reference.

So in short, a bug in the data.

Bruce

On Sat, Dec 8, 2012 at 2:18 PM, Ron Jerome <[hidden email]> wrote:
> Hi Folks,
>
> I've run into an issue with cs:group elements and seek some clarification on
> the spec.
>
> I have a group which contains a number of elements rendered either directly
> from variables for indirectly from macros.
>
> My interpretation of the spec is that ALL of the variables/macros have to be
> empty before the group is suppressed, but in the case of a group with
> multiple variables/macros, this can produce some strange output.
>
> Here is my specific case...
>
>         <group delimiter="">
>           <text term="in" suffix=": " text-case="capitalize-first"/>
>           <text macro="container-contributors" prefix=" " suffix=": "/>
>           <text macro="container-title" suffix="."/>
>           <label variable="page" form="short" text-case="lowercase"
> suffix=". " prefix="  &#8211; "/>
>           <text variable="page" suffix=","/>
>         </group>
>
> In this case, both "container-contributors" and "container-title" macros
> evaluate empty but the "page" variable is there, so it creates strange
> output like this...
>
> "In:   – pp. 329–368"
>
> Seems to me in this case, the whole thing should be suppressed.
>
> Am I misinterpreting the spec?
>
> Ron.
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel




--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel



------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
xbiblio-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel