Conversation
| .filter(Boolean) | ||
|
|
||
| return { | ||
| unserialized: bib, |
There was a problem hiding this comment.
will remove but it's helpful for testing
| @@ -0,0 +1,166 @@ | |||
| /** | |||
There was a problem hiding this comment.
You're putting the rest of the codebase to shame with all this detailed documentation! Nicely done though it definitely helps make it easy to understand what is going on.
| const parallels = MarcSerializer.findParallelFields(bib, field) | ||
| parallels.forEach((p) => { | ||
| Object.assign(p, MarcSerializer.buildSourceWithMasking(p, matchingRule)) | ||
| }) |
There was a problem hiding this comment.
Is this an effort to link parallel fields to primary fields so that they can be visually linked on the front-end? Aren't we just rendering 880s as is?
Incidentally I'm not seeing known 880 values come through when viewing/api/v0.1/discovery/resources/b22144813.marclocally
There was a problem hiding this comment.
Ah this may be wrong then– I'm trying to find the parallels of suppressed fields and suppress them, but otherwise pass parallels through
There was a problem hiding this comment.
@nonword can you give an example of an 880 we'd expect to see in that bib?
| bib: { | ||
| id: bib.id, | ||
| nyplSource: bib.nyplSource, | ||
| fields: suppressedVarFields |
There was a problem hiding this comment.
I'm not sure if this variable is misnamed, but something here does not seem right. Why are you returning something called suppressed?
There was a problem hiding this comment.
Good point, renamed to serialized to mean all the processed varfields
|
|
||
| if (!linkNumbers.length) return [] | ||
|
|
||
| return bib.varFields.filter((f) => { |
There was a problem hiding this comment.
I'm finding this chunk hard to grok. Can you use some more descriptive variable names and/or pull some of these array method callbacks into named functions?
There was a problem hiding this comment.
Broken down into some more chunks
| subfields: (field.subfields || []).map((subfield) => { | ||
| let content = subfield.content | ||
| if ( | ||
| (rule.subfieldSpec.directive === 'include' && |
There was a problem hiding this comment.
I know this is in the original code, but do we know why this is logically here? If the directive says include but it is not present in the subfield spec, wouldn't we just skip it? Wouldn't this add [redacted] for fields that don't have content? @nonword maybe you have some insight?
There was a problem hiding this comment.
As discussed elsewhere, yeah, I have no insight on the history of this, but agree we should probably simply empty/null the value (or remove the subfield entirely) if the intent is to simply hide suppressed fields
Sean's request is that we should remove those subfields– as far as I can tell we might as well do this on the annotated MARC too. Updated accordingly cc @charmingduchess @nonword |
|
@nonword I wrote these rules/updated the MARC serializer with the big assumption that since specific field tags and subfields weren't mentioned, they don't need to be included in the rules or handled any more in the serializer? Is that right |
4 participants
Adds MARC endpoint which should:
Also adds new MARC rules as recently defined by Paul/Tomasz– much less suppression than the AM.
Also minor update to AM serializer: redacted subfields are now just removed, not returned as
'redacted'.good test:
b22144813