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

Reply via email to