<div dir="ltr">On 13 July 2017 at 12:13, Patrick Hochstenbach <span dir="ltr"><<a href="mailto:Patrick.Hochstenbach@ugent.be" target="_blank">Patrick.Hochstenbach@ugent.be</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">There is no sorting of MARC fields in the Fix language. One can add fields by `marc_add` fixes. The order of the new fields is in the order you execute the marc_add commands.<br></blockquote><div><br></div><div>I am still trying to understand if sorting is needed (in our use case, at least):</div><div><br></div><div>One place where the MARC spec mention field order is this: "<span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium;text-align:justify">Control fields precede data fields in the record and are arranged in the same sequence as the corresponding entries in the directory."</span></div><div><br></div><div><a href="https://www.loc.gov/marc/specifications/specrecstruc.html">https://www.loc.gov/marc/specifications/specrecstruc.html</a><br></div><div><br></div><div>If we assume that this is true and control fields should come before data fields, then adding control fields using 'marc_add' would result on MARC data that violate this assumption.</div><div><br></div><div>A quick fix [to avoid the need for sorting] here would be to allow inserting new fields before "100" field (= after the last control field). </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">With the marc_paste (the nephews of marc_copy and marc_cut) you can decide where in the record the new marc record should be pasted:<br>
<br>
# Paste mycopy after the last 300 field<br>
marc_paste(mycopy, at:300)<br>
<br>
<a href="https://metacpan.org/pod/Catmandu::Fix::marc_paste" rel="noreferrer" target="_blank">https://metacpan.org/pod/<wbr>Catmandu::Fix::marc_paste</a></blockquote><div><br></div><div>This is a cool feature! :)</div><div><br></div><div>What would happen if there are no "300" fields in the record?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
In general there is no condition how MARC records could be sorted. Marc tags can be repeated:<br>
<br>
500 $aZorro, this is my First note<br>
500 $aAlso a nice not, but not the first<br>
500 $aWell this is the last note<br>
<br>
Sorting the notes will result in errors in the catalogging. MARC is not a table or database format but markup language ..<br></blockquote><div><br></div><div>Agreed. If sorting were to be implemented it would need to preserve the order of the existing fields that have the same code.</div><div><br></div><div>Uldis</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5">> On 13 Jul 2017, at 10:25, Uldis Bojars <<a href="mailto:captsolo@gmail.com">captsolo@gmail.com</a>> wrote:<br>
><br>
> set_array(ok_fields, FMT, LDR,<br>
> 008, 040, 041, 075, 100,<br>
> 240, 245, 246, 260,<br>
> 377, 380, 388, 400, 490,<br>
> 600, 630, 650, 670, 677,<br>
> 700, 720, 908, 910)<br>
><br>
> do marc_each()<br>
><br>
> copy_field(record.0.0, fld_type)<br>
><br>
> unless in(fld_type, ok_fields)<br>
> remove_field(record)<br>
> end<br>
><br>
> remove_field(fld_type) # is this needed?<br>
><br>
> end<br>
><br>
> remove_field(ok_fields)<br>
<br>
</div></div></blockquote></div></div></div>