Bug 13600 - XSLT: 8xx not showing if there is no 4xx
Summary: XSLT: 8xx not showing if there is no 4xx
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Nick Clemens
QA Contact: Testopia
URL:
Keywords: rel_22_11_candidate
: 22820 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-20 14:20 UTC by Nicole C. Engard
Modified: 2023-07-05 23:44 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
22.11.00


Attachments
Bug 13600 - XSLT: 8xx not showing if there is no 4xx (4.80 KB, patch)
2015-06-12 02:15 UTC, Winona Salesky
Details | Diff | Splinter Review
Bug 14280: Add branches fields to discharges letters (2.99 KB, text/plain)
2015-06-12 20:16 UTC, Nick Clemens
Details
[SIGNED OFF] Bug 13600 - XSLT: 8xx not showing if there is no 4xx (4.83 KB, patch)
2015-06-12 20:21 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 13600 - XSLT: 8xx not showing if there is no 4xx (9.08 KB, patch)
2015-06-17 02:02 UTC, Winona Salesky
Details | Diff | Splinter Review
Bug 13600 - XSLT: 8xx not showing if there is no 4xx (10.60 KB, patch)
2015-06-25 14:28 UTC, Winona Salesky
Details | Diff | Splinter Review
Bug 13600 - XSLT: 8xx not showing if there is no 4xx (12.28 KB, patch)
2015-06-25 14:36 UTC, Winona Salesky
Details | Diff | Splinter Review
Bug 13600: XSLT - 8xx not showing if there is no 4xx (25.23 KB, patch)
2022-09-16 11:40 UTC, Nick Clemens
Details | Diff | Splinter Review
Different records with different series statments (2.24 KB, application/marc)
2022-09-16 11:42 UTC, Nick Clemens
Details
Bug 13600: Screenshots of results before and after (494.53 KB, application/pdf)
2022-09-17 21:10 UTC, David Nind
Details
Bug 13600: (follow-up) Add separator between different series fields (2.83 KB, patch)
2022-10-24 16:27 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 13600: XSLT - 8xx not showing if there is no 4xx (25.28 KB, patch)
2022-10-25 00:15 UTC, David Nind
Details | Diff | Splinter Review
Bug 13600: (follow-up) Add separator between different series fields (2.88 KB, patch)
2022-10-25 00:15 UTC, David Nind
Details | Diff | Splinter Review
Bug 13600: (follow-up) Add seperator on the OPAC (2.40 KB, patch)
2022-11-03 09:41 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 13600: XSLT - 8xx not showing if there is no 4xx (25.34 KB, patch)
2022-11-09 18:01 UTC, Tomás Cohen Arazi
Details | Diff | Splinter Review
Bug 13600: (follow-up) Add separator between different series fields (2.93 KB, patch)
2022-11-09 18:01 UTC, Tomás Cohen Arazi
Details | Diff | Splinter Review
Bug 13600: (follow-up) Add seperator on the OPAC (2.46 KB, patch)
2022-11-09 18:01 UTC, Tomás Cohen Arazi
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2015-01-20 14:20:59 UTC
In records with series field(s) 800/810/830 only (no 4XX series), no series are displayed. 

The MARC21 rules say:


"An 810 field is usually justified by a series statement (field 490) or a general note (field 500) relating to the series."


"usually" means it should show even if there is no 490

http://www.loc.gov/marc/bibliographic/bd810.html
Comment 1 Winona Salesky 2015-06-05 02:44:43 UTC
How about if there is 490$0 or 490$# ? Should the 8xx display in that case as well? 

(In reply to Nicole C. Engard from comment #0)
> In records with series field(s) 800/810/830 only (no 4XX series), no series
> are displayed. 
> 
> The MARC21 rules say:
> 
> 
> "An 810 field is usually justified by a series statement (field 490) or a
> general note (field 500) relating to the series."
> 
> 
> "usually" means it should show even if there is no 490
> 
> http://www.loc.gov/marc/bibliographic/bd810.html
Comment 2 Nicole C. Engard 2015-06-05 13:14:55 UTC
(In reply to Winona Salesky from comment #1)
> How about if there is 490$0 or 490$# ? Should the 8xx display in that case
> as well? 

You know .. I don't know. The examples on the 810 documentation look like it should so not matter what the indicators ... 

On the 490 documentation the 830 only shows if the indicator is 1 - and so maybe if the indicator is 1 we shouldn't show the 8xx because it will be duplicate info.

Anyone else have any feedback here?
Comment 3 Heather 2015-06-05 15:23:18 UTC
Yes--the 8XX should always display.  The 4XX is transcribed from the item, so would be present only if the series statement appears on the item.  With a 490 1_ there should be a companion 8XX, with the 490 field transcribing the series statement from the item & the 8XX containing the series statement added entry.  (These fields are a holdover from card printing, when you wanted the 4XX printed in parentheses as transcribed & then an added entry card printed with the form of the series as traced.)

There could be a case where there is a 490 0_ and a 500 and an 8XX, e.g. (made up example):
490 0 _ Ballantine science fiction masters
500 _ _ Fifth in the Captain Proton series.
800 1 _ Smith, Joanna. $t Captain Proton series ; $v 5.

In this made up example, the series is not traced because it's a publishers' artificial marketing series, but it's important to transcribe it for identification of the edition.  Access is created for the "series" of novels featuring the character in order of publication, since people look for novels that way.

This is a record where the 8XX field is justified by a 500 note:
http://keys.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=3301

More typically, you will have a 490 1_ paired with an 830 0_.
Comment 4 Winona Salesky 2015-06-06 02:41:03 UTC
Thanks Heather. That is very helpful. 

So to translate that into code, I could say, always display 8xx, but only display 490 where ind1 is NOT 1 (not traced). 

Is that accurate?
-Winona
Comment 5 Heather 2015-06-08 15:33:47 UTC
(In reply to Winona Salesky from comment #4)
> Thanks Heather. That is very helpful. 
> 
> So to translate that into code, I could say, always display 8xx, but only
> display 490 where ind1 is NOT 1 (not traced). 
> 
> Is that accurate?
> -Winona

It sounds accurate, Winona.  I think you could also say, "...only display 490 where ind1 is zero."  The 490 0_ display has traditionally been in parentheses, c.f. display examples here: http://www.loc.gov/marc/bibliographic/bd490.html  It has traditionally not had any prefix or label to the field.

8XX fields have not traditionally displayed in parentheses, but have a prefix.  Why, I don't know, but that's the way it is!  Displays in systems I've seen vary, but other systems I've seen tend to have a prefix and group all displayed series entries, e.g.:
Series:	Magic ex libris ; bk. 2
	DAW book collectors ; no. 1629

In this case, only "Magic ex libris" is a traced series (830 field), searchable via a series or title index search as well as a keyword search.  "DAW book collectors" is untraced (490 0_ field) so is searchable only via a keyword search.

Hope this helps!
--h2
Comment 6 Winona Salesky 2015-06-08 19:31:57 UTC
I can do that. What should happen where 490 ind1 is blank? In the example below if 490 ind1 is blank the field will be suppressed. It might make more sense to show the field as the default, and suppress it only when explicitly stated (by the indicator). Although I may be miss understanding how the field is coded. 

Thanks for the help,

-Winona


(In reply to Heather from comment #5)
> (In reply to Winona Salesky from comment #4)
> > Thanks Heather. That is very helpful. 
> > 
> > So to translate that into code, I could say, always display 8xx, but only
> > display 490 where ind1 is NOT 1 (not traced). 
> > 
> > Is that accurate?
> > -Winona
> 
> It sounds accurate, Winona.  I think you could also say, "...only display
> 490 where ind1 is zero."  The 490 0_ display has traditionally been in
> parentheses, c.f. display examples here:
> http://www.loc.gov/marc/bibliographic/bd490.html  It has traditionally not
> had any prefix or label to the field.
> 
> 8XX fields have not traditionally displayed in parentheses, but have a
> prefix.  Why, I don't know, but that's the way it is!  Displays in systems
> I've seen vary, but other systems I've seen tend to have a prefix and group
> all displayed series entries, e.g.:
> Series:	Magic ex libris ; bk. 2
> 	DAW book collectors ; no. 1629
> 
> In this case, only "Magic ex libris" is a traced series (830 field),
> searchable via a series or title index search as well as a keyword search. 
> "DAW book collectors" is untraced (490 0_ field) so is searchable only via a
> keyword search.
> 
> Hope this helps!
> --h2
Comment 7 Heather 2015-06-08 19:58:43 UTC
(In reply to Winona Salesky from comment #6)
> I can do that. What should happen where 490 ind1 is blank? In the example
> below if 490 ind1 is blank the field will be suppressed. It might make more
> sense to show the field as the default, and suppress it only when explicitly
> stated (by the indicator). Although I may be miss understanding how the
> field is coded. 
> 
> Thanks for the help,
> 
> -Winona
> 
> 
> (In reply to Heather from comment #5)
> > (In reply to Winona Salesky from comment #4)
> > > Thanks Heather. That is very helpful. 
> > > 
> > > So to translate that into code, I could say, always display 8xx, but only
> > > display 490 where ind1 is NOT 1 (not traced). 
> > > 
> > > Is that accurate?
> > > -Winona
> > 
> > It sounds accurate, Winona.  I think you could also say, "...only display
> > 490 where ind1 is zero."  The 490 0_ display has traditionally been in
> > parentheses, c.f. display examples here:
> > http://www.loc.gov/marc/bibliographic/bd490.html  It has traditionally not
> > had any prefix or label to the field.
> > 
> > 8XX fields have not traditionally displayed in parentheses, but have a
> > prefix.  Why, I don't know, but that's the way it is!  Displays in systems
> > I've seen vary, but other systems I've seen tend to have a prefix and group
> > all displayed series entries, e.g.:
> > Series:	Magic ex libris ; bk. 2
> > 	DAW book collectors ; no. 1629
> > 
> > In this case, only "Magic ex libris" is a traced series (830 field),
> > searchable via a series or title index search as well as a keyword search. 
> > "DAW book collectors" is untraced (490 0_ field) so is searchable only via a
> > keyword search.
> > 
> > Hope this helps!
> > --h2

Hey, Winona--

The 490 ind1 must never be blank--blank is not a valid value.  The 490 first indicator must be zero or one.  (The 490 second indicator must be blank, but the first indicator must be zero or one.)  The required values are here:
http://www.loc.gov/marc/bibliographic/bd490.html

Hope this helps!
--h2
Comment 8 Winona Salesky 2015-06-12 02:15:54 UTC Comment hidden (obsolete)
Comment 9 Nick Clemens 2015-06-12 20:16:43 UTC Comment hidden (obsolete)
Comment 10 Nick Clemens 2015-06-12 20:21:30 UTC Comment hidden (obsolete)
Comment 11 Nick Clemens 2015-06-12 20:31:19 UTC
This works as described and is an improvement so signing off.

All below are just wishlist:

Punctuation could be better, between fields is ';' would be nice to see as '|' as on others 

Also, 8xx fields seems to be ending in ':' regardless of field ending in record

Would also be nice to have some indication between author/title in the 8xx, maybe title in italics?

(And apologies for mis-attached patch earlier)
Comment 12 Winona Salesky 2015-06-15 14:48:09 UTC
These are all simple additions and can be added. I will have an amended patch up by tonight. Thanks for the feedback!
-Winona


(In reply to Nick Clemens from comment #11)
> This works as described and is an improvement so signing off.
> 
> All below are just wishlist:
> 
> Punctuation could be better, between fields is ';' would be nice to see as
> '|' as on others 
> 
> Also, 8xx fields seems to be ending in ':' regardless of field ending in
> record
> 
> Would also be nice to have some indication between author/title in the 8xx,
> maybe title in italics?
> 
> (And apologies for mis-attached patch earlier)
Comment 13 Heather 2015-06-15 15:45:04 UTC
(In reply to Winona Salesky from comment #12)
> These are all simple additions and can be added. I will have an amended
> patch up by tonight. Thanks for the feedback!
> -Winona
> 
> 
> (In reply to Nick Clemens from comment #11)
> > This works as described and is an improvement so signing off.
> > 
> > All below are just wishlist:
> > 
> > Punctuation could be better, between fields is ';' would be nice to see as
> > '|' as on others 
> > 
> > Also, 8xx fields seems to be ending in ':' regardless of field ending in
> > record
> > 
> > Would also be nice to have some indication between author/title in the 8xx,
> > maybe title in italics?
> > 
> > (And apologies for mis-attached patch earlier)

An indication between author & title in the 800 & 810 would be great, but I think that if the title were in italics, it would be the only italics in the display.  Also, no other titles in displays are in italics, and some of the other bib systems (e.g., Worldcat.org) don't display titles in italics.  The MARC21 format recommends a period/full stop between authors & titles in most (or all) fields, and the author & title would be hyperlinked & clickable, right?  So something like in our catalog, with the series hyperlinked, e.g. in this record, with the comma after "Patrick" replaced with a period/full stop?

http://keys.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=3286
Series: O'Brian, Patrick. Aubrey/Maturin novels: 1.

--heather
Comment 14 Katrin Fischer 2015-06-15 18:42:44 UTC
Hm, I am with Heather on the italics - what about he separator | Nick mentioned? For when the record is part of multiple series? I'd think it wouldn't happen often, but on the other hand... nothing is impossible I have learned.
Comment 15 Heather 2015-06-15 20:11:43 UTC
Yes--multiple series do happen!  I like the idea of a pipe between series entries.  Maybe it would look cleaner without a period/full stop at the end:

Series: Hines, Jim C. Magic ex libris: 1 | Wizard essential codices: 342 |  Fantasy reading group favorites: v. 45

The single series entry may still look fine without the period/full stop at the end:

Series: O'Brian, Patrick. Aubrey/Maturin novels: 1

--heather
P.S. Don't tell other catalogers I suggested eliminating the Very Traditional Period/Full Stop at the end of the series entry!:)
Comment 16 Heather 2015-06-15 20:14:38 UTC
(In reply to Heather from comment #15)
> Yes--multiple series do happen!  I like the idea of a pipe between series
> entries.  Maybe it would look cleaner without a period/full stop at the end:
> 
> Series: Hines, Jim C. Magic ex libris: 1 | Wizard essential codices: 342 | 
> Fantasy reading group favorites: v. 45
> 
> The single series entry may still look fine without the period/full stop at
> the end:
> 
> Series: O'Brian, Patrick. Aubrey/Maturin novels: 1
> 
> --heather
> P.S. Don't tell other catalogers I suggested eliminating the Very
> Traditional Period/Full Stop at the end of the series entry!:)

ETA: I forgot to mention re. "Also, 8xx fields seems to be ending in ':' regardless of field ending in record," that this looks OK to me.  Traditionally there is a "space, semi-colon, space" between the title and the number, but the colon snug against the title followed by a space looks good--it's neat and clear.
Comment 17 Katrin Fischer 2015-06-15 20:16:32 UTC
I won't, because I like it :)
Comment 18 Heather 2015-06-15 20:18:28 UTC
(In reply to Katrin Fischer from comment #17)
> I won't, because I like it :)

It is our secret!:)
Comment 19 Nick Clemens 2015-06-15 20:46:40 UTC
(In reply to Heather from comment #16)
> ETA: I forgot to mention re. "Also, 8xx fields seems to be ending in ':'
> regardless of field ending in record," that this looks OK to me. 
> Traditionally there is a "space, semi-colon, space" between the title and
> the number, but the colon snug against the title followed by a space looks
> good--it's neat and clear.

I agree with that, but the case where there is no volume number I think the ':' looks a bit odd

Italics was a radical idea, full stop does seem more reasonable.
Comment 20 Katrin Fischer 2015-06-15 20:50:44 UTC
I think removing the : if there is no number/volume would make sense to me.
Comment 21 Heather 2015-06-15 20:56:49 UTC
Just removing the ":" may look great.  Traditionally the " ; " precedes the numbering in the $v if it is present.  If there was no 8XX $v, then there was no punctuation at the end of the $t, because the field displayed within parentheses.  I think it would be fine without terminal punctuation and/or punctuation between $t & $v fields, e.g.:

Series: Hines, Jim C. Magic ex libris 1 | Wizard essential codices 342 |  Fantasy reading group favorites v. 45

Series: Tolkien, J.R.R. Lord of the rings 2 | Ballantine basics | Best 100 books of the 20th century no. 3

--h2
Comment 22 Katrin Fischer 2015-06-16 07:07:55 UTC
Hm, not sure about generally removing the separator between the title and the volumne - some 'volumes' might be more textual. It might be more clear with something in between.
Comment 23 Winona Salesky 2015-06-16 13:28:51 UTC
I also like the ':' (currently it is ':' should it be ';'?) between title and volumne, a solution would be to make it conditional, so it only appears if a $v is present. 

I will also change the separator between multiple fields. I would suggest leaving terminal punctuation, simply because most of the fields in the current xslt do use it.

Let me know what you all think, and I will try to get an amended patch up this evening. 
Thanks!
-Winona


(In reply to Katrin Fischer from comment #22)
> Hm, not sure about generally removing the separator between the title and
> the volumne - some 'volumes' might be more textual. It might be more clear
> with something in between.
Comment 24 Heather 2015-06-16 15:17:55 UTC
(In reply to Winona Salesky from comment #23)
> I also like the ':' (currently it is ':' should it be ';'?) between title
> and volumne, a solution would be to make it conditional, so it only appears
> if a $v is present. 
> 
> I will also change the separator between multiple fields. I would suggest
> leaving terminal punctuation, simply because most of the fields in the
> current xslt do use it.
> 
> Let me know what you all think, and I will try to get an amended patch up
> this evening. 
> Thanks!
> -Winona
> 
> 
> (In reply to Katrin Fischer from comment #22)
> > Hm, not sure about generally removing the separator between the title and
> > the volumne - some 'volumes' might be more textual. It might be more clear
> > with something in between.

Very good point about the textual nature of some volume numbering--I hadn't thought of that!

The RDA proscribed punctuation for data in 4XX & 8XX $v is in rule D.1.2.7, "Precede the numbering within a series or sub-series or multipart monographic resource by a semicolon."  (It was the same in AACR2 & AACR2R.) Of course, not everyone catalogs according to RDA.  But if this standard is to be implemented, then the $v in the 4XX & the 8XX would be preceded by a space-semicolon-space.

As for terminal punctuation, MARC21 is inconsistent, e.g. 8XX ends with a period/full-stop, 4XX, 24X & 78X do not have terminal punctuation at all, etc.  If the MARC21 standard is to be followed, then there should be a period/full-stop at the end of 8XX fields (and nothing at the end of 4XX fields).

On this record, the 24X fields & 6XX fields lack terminal punctuation, and different field separators are used for multiple field displays (semicolons for the 24X field, pipes for the 6XX fields):
http://keys.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=35979

The 24X field separators may be custom--I'm sorry, but I'm not sure.

I think it would be great to have standard field separators for multiple field displays in Koha, whatever they are.  If the RDA proscribed punctuation of a semicolon is to be implemented preceding the $v field(s) in 4XX & 8XX fields, then perhaps pipes should be used as field separators.  And, in the future, perhaps such pipes should be used as field separators for other multiple field displays.

Cheerio!
--h2
Comment 25 Katrin Fischer 2015-06-16 15:27:09 UTC
> I also like the ':' (currently it is ':' should it be ';'?) between title
> and volumne, a solution would be to make it conditional, so it only appears
> if a $v is present. 

I like the conditional and would like the ; a bit better (less likely to be used in the title?)


>And, in the future, perhaps such pipes should be used as field separators for >other multiple field displays.

I think the trend goes to | currently - we already have that in several fields now. :) What I'd like to see is have them wrapped in a span with a class. So if you don't like the |, you can easily change it. I think we have done that in one place at least already.

I am not sure how close we need to stick to the MARC21 standard here as we are building a 'normal view' targetted at patrons and all library staff. I know that the ending punctuation '.' has caused some questions here in the past - same for the / at the end of the title. I feel like most catalogs here don't have that, but they are mostly not MARC21 internally either.
Comment 26 Heather 2015-06-16 15:36:36 UTC
(In reply to Katrin Fischer from comment #25)
> > I also like the ':' (currently it is ':' should it be ';'?) between title
> > and volumne, a solution would be to make it conditional, so it only appears
> > if a $v is present. 
> 
> I like the conditional and would like the ; a bit better (less likely to be
> used in the title?)
> 
> 
> >And, in the future, perhaps such pipes should be used as field separators for >other multiple field displays.
> 
> I think the trend goes to | currently - we already have that in several
> fields now. :) What I'd like to see is have them wrapped in a span with a
> class. So if you don't like the |, you can easily change it. I think we have
> done that in one place at least already.
> 
> I am not sure how close we need to stick to the MARC21 standard here as we
> are building a 'normal view' targetted at patrons and all library staff. I
> know that the ending punctuation '.' has caused some questions here in the
> past - same for the / at the end of the title. I feel like most catalogs
> here don't have that, but they are mostly not MARC21 internally either.

Yes--the semicolon is rarely used in titles.  And your idea about the span & class would be great!

I think the slash in the 245 ("/") is misapplied.  Most catalogs don't have it at the end of 245 subfields because it is not terminal punctuation.  It is not supposed to be at the end of a field, but is supposed to *precede* the 245 $c (statement of responsibility) only if the $c is present.  So it is like this semicolon for the 4XX & 8XX $v that we are discussing--it is supposed to appear preceding a field only if the field is present.  Have a slash appear as terminal punctuation is not proscribed by AACR2, AACR2R, or RDA.  (RDA D.1.2.2, "Precede the first statement of responsibility by a diagonal slash.  Precede each subsequent statement of responsibility by a semicolon.")

--h2
Comment 27 Winona Salesky 2015-06-17 02:02:54 UTC Comment hidden (obsolete)
Comment 28 Nick Clemens 2015-06-24 20:30:06 UTC
Working:
OPAC now shows '|' separator
';' is enforced as title/volume separator
no punctuation if volume isn't present

Needs fixed:
Staff side separator is still ';' SHOULD BE '|'
':' is enforced as title/volume separator - SHOULD BE ';'
All fields have ending':' if volume is not present
Comment 29 Winona Salesky 2015-06-25 14:28:47 UTC Comment hidden (obsolete)
Comment 30 Winona Salesky 2015-06-25 14:36:25 UTC
Created attachment 40637 [details] [review]
Bug 13600 - XSLT: 8xx not showing if there is no 4xx

Removes dependency on 490 ind1 for 8xx display. 8xx will always display.
Adds span class="separator" | between multiple series, changes : before $v to a conditional ;
Adds patch to staff details interface.

Test Plan:
1) Apply this patch
2) Ensure you are using the default XSLT setting for the staff and opac details view.
3) Find or create a record with MARC tags 800, 810, 830
4) Check display of 8xx tags, should always display if present in the record.
6) Repeat test for the staff interface
Comment 31 Winona Salesky 2015-06-25 14:37:31 UTC
Sorry about that, the original patch did not include a fix for the staff client. 
-Winona
Comment 32 Nick Clemens 2015-06-25 21:14:38 UTC
800s look good.

And now my apologies for incomplete testing previously

1 - 400s need the semicolon between title/volume
2 - there is no '|' between 440 / 490 / 8xxs 

(multiple 440s and 490s are separated by '|'  so good there)


I will mention that author dates are not displayed in series field, and the links for series use only the author name in their search so:

800 1_ $aAdams, Douglas, $d 1952-2001. 4t Dirk Gently’s Holistic Detective Agency

Searches for se,phr:"Adams,Douglas" instead of se,phr:"Dirk Gently..."

I think it is out of scope here, but wondering if the behavior is correct
Comment 33 David Cook 2022-09-16 04:59:19 UTC
It looks like this ended up suffering from scope creep?

I had someone raise this issue locally the other day, so it would be interesting to see how Koha wants to move forward.

For now, locally we're going to update the 490 data, so that the 830 shows.
Comment 34 Nick Clemens 2022-09-16 11:40:46 UTC
Created attachment 140705 [details] [review]
Bug 13600: XSLT - 8xx not showing if there is no 4xx

This patch adjusts XSLT so that series tag displays if any 440,490,800,810,830 is present

It also adjusts 8xx to display even if 490 ind 1 = 1 is not present

To test:
1 - Check records with multiple series tag
2 - Confirm display is correct
Comment 35 Nick Clemens 2022-09-16 11:42:15 UTC
Created attachment 140706 [details]
Different records with different series statments

Import this file - search for 'this is a series' - note display in results and detail pages
Comment 36 David Nind 2022-09-17 21:10:49 UTC
Created attachment 140736 [details]
Bug 13600: Screenshots of results before and after

I've tested (using koha-testing-docker) with the sample records provided (these made it much easier to test, so thanks for providing these!).

I'm not a cataloguer, so have captured screenshots of before and after (attached) and made notes on the differences.

There was a lot of discussion about the correct punctuation, but it is a little over my head and maybe should be a separate bug(s).

If this is what is expected, I'd be happy to sign off.

Otherwise, happy to leave for experienced cataloguers to comment and signoff.

Notes on differences
--------------------

See the attachment with screenshots of the differences before and after the patch is applied (have included screenshots of the search results before and after, as well as individual before and after screenshots to make it easier to compare).

This is a series with 440 and 490
- No change before and after the patch is applied (as expected)
- There are two ; displayed for the Journal of polymer science
- The second 490 "Environmental science research" (has a 1 indicator) isn't displayed

This is a series with 8xx and 490
- No change before and after the patch is applied
- There are two ; displayed for the Journal of polymer science (no change before and after the patch applied)
- The second 490 "Environmental science research" (has a 1 indicator) isn't displayed
- There is no | between Beagle Expedition and AMG all music guide series (I'm not sure whether there should be or not)

This is a series with multiple 440 and 8xx but no 490
- 8xx tags displayed after the patch is applied (as expected)
- There are two ; displayed for the Journal of polymer science (no change before and after the patch applied)
- There is no | or spacing between Environmental science research and Abellán, Fernando (displays as Environmental science research ; v. 4Abellán, Fernando ;)

This is a series with multiple 8xx but no 4xx
- 8xx tags displayed after the patch is applied (as expected)
- There is no | between Beagle Expedition and AMG all music guide series (I'm not sure whether there should be or not)
Comment 37 Katrin Fischer 2022-09-19 20:18:00 UTC
Tested with some of our records and no regressions found (display before and after the patch is applied are the same). It looks like there might be some punctuation issues unrelated to the patch in David's report - maybe good to look into those on a separate bug.
Comment 38 Heather 2022-10-21 17:54:48 UTC
Here's some Cataloger Opinions on Punctuation (in case it's helpful!):

I looked at the sample records--lots of fields seem to be missing required indicators, but I guess that doesn't affect this?

First record, "This is a series with multiple 8xx but no 4xx" has correct punctuation.

Second record, "This is a series with multiple 440 and 8xx but no 490" has incorrect punctuation in second 440 field:  "Chronicles of Prydain ǂv 2" should be "Chronicles of Prydain ;ǂv 2"  It's the same in the 3rd records, "This is a series with 8xx and 490," with the 490 lacking a semicolon preceding the subfield v.  Given that this MARC record lacks the required semicolon preceding the subfield v, yet a semicolon is supplied in the display, it seems that Koha is supplying semicolons as display constants, but this is not permitted in MARC21 for field 490:
https://www.loc.gov/marc/bibliographic/bd490.html
The only display constants permitted in MARC21 are optional parentheses enclosing the display of the entire field.

So catalogers are required to enter a semicolon preceding a subfield v in all MARC21 series fields (4XX &/or 8XX), so Koha shouldn't be supplying semicolon display constants.  I think this supplying of a semicolon display constant is why there are weird double-semicolons.  So maybe a developer could apply Developer Code Magic to stop Koha from supplying these unallowed semicolon display constants?

As for the behavior of record "This is a series with 440 and 490" not displaying the 490 with a first indicator of 1, that seems like correct behavior--that is an incorrect indicator, since "1" should only be used when the record has a paired 8XX field to provide the series added entry.  (The correct indicator in the absence of a paired 8XX field is 490 0_).

--h2
Comment 39 Nick Clemens 2022-10-24 16:27:17 UTC
Created attachment 142530 [details] [review]
Bug 13600: (follow-up) Add separator between different series fields

This patch checks for an upcoming series tag, and adds a separator if one is found
Comment 40 Nick Clemens 2022-10-24 16:28:30 UTC
I fixed the issue with separators by checking ahead for upcoming series tags

The semicolons should be handled on a new bug as we supposedly strip punctuation, then add it back, but it doesn't seem to be working
Comment 41 David Nind 2022-10-25 00:15:24 UTC
Created attachment 142588 [details] [review]
Bug 13600: XSLT - 8xx not showing if there is no 4xx

This patch adjusts XSLT so that series tag displays if any 440,490,800,810,830 is present

It also adjusts 8xx to display even if 490 ind 1 = 1 is not present

To test:
1 - Check records with multiple series tag
2 - Confirm display is correct

Signed-off-by: David Nind <david@davidnind.com>
Comment 42 David Nind 2022-10-25 00:15:31 UTC
Created attachment 142589 [details] [review]
Bug 13600: (follow-up) Add separator between different series fields

This patch checks for an upcoming series tag, and adds a separator if one is found

Signed-off-by: David Nind <david@davidnind.com>
Comment 43 David Nind 2022-10-25 00:23:21 UTC
Have signed off based on the follow-up, and that semicolons will be addressed in another bug.

Thanks Heather for your great comments!
Comment 44 Katrin Fischer 2022-11-02 23:01:22 UTC
Do we need the separator (last patch) for the OPAC too?
Comment 45 Nick Clemens 2022-11-03 09:41:47 UTC
Created attachment 143069 [details] [review]
Bug 13600: (follow-up) Add seperator on the OPAC
Comment 46 Tomás Cohen Arazi 2022-11-09 18:01:15 UTC
Created attachment 143566 [details] [review]
Bug 13600: XSLT - 8xx not showing if there is no 4xx

This patch adjusts XSLT so that series tag displays if any 440,490,800,810,830 is present

It also adjusts 8xx to display even if 490 ind 1 = 1 is not present

To test:
1 - Check records with multiple series tag
2 - Confirm display is correct

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 47 Tomás Cohen Arazi 2022-11-09 18:01:23 UTC
Created attachment 143567 [details] [review]
Bug 13600: (follow-up) Add separator between different series fields

This patch checks for an upcoming series tag, and adds a separator if one is found

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 48 Tomás Cohen Arazi 2022-11-09 18:01:31 UTC
Created attachment 143568 [details] [review]
Bug 13600: (follow-up) Add seperator on the OPAC

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 49 Tomás Cohen Arazi 2022-11-09 18:29:45 UTC
Pushed to master for 22.11.

Nice work everyone, thanks!
Comment 50 Phil Ringnalda 2023-07-05 23:44:08 UTC
*** Bug 22820 has been marked as a duplicate of this bug. ***