Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optionally encode marked literals as MARC record attributes. #404

Closed
wants to merge 1 commit into from

Conversation

blackwinter
Copy link
Member

This is a rather "dirty" fix. The "cleaner" solution would probably be to implement the same mechanism that SimpleXmlEncoder uses.

Fixes #402.

Copy link
Member

@dr0i dr0i left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this is the solution for building the necessary structure, I think I now understand my (and @TobiasNx ) problem - it's just naming. Because the expression "attribute(Marker)" implicitly references all kind of "attributes" (i.a. the "tag" in "<marc:controlfield tag=...") and not only the "recordAttribute". But what is really meant is just the latter.
So I propose to change variable names and most importantly the API naming of "setAttributeMarker" to "setRecordAttributeMarker" (see https://www.loc.gov/standards/marcxml/xml/spy/spy.html).

@blackwinter
Copy link
Member Author

So I propose to change variable names and most importantly the API naming of "setAttributeMarker" to "setRecordAttributeMarker"

This was initially meant as a feature, but if we consider it a bugfix, we can approach it differently: Encode type (and id?) literals as attributes (similar to leader being treated specially).

@TobiasNx
Copy link
Contributor

TobiasNx commented Oct 5, 2021

While this is the solution for building the necessary structure, I think I now understand my (and @TobiasNx ) problem - it's just naming. Because the expression "attribute(Marker)" implicitly references all kind of "attributes" (i.a. the "tag" in "<marc:controlfield tag=...") and not only the "recordAttribute". But what is really meant is just the latter. So I propose to change variable names and most importantly the API naming of "setAttributeMarker" to "setRecordAttributeMarker" (see https://www.loc.gov/standards/marcxml/xml/spy/spy.html).

But is there such a difference between the other attributes and the recordAttributes?

id
type
tag
ind1
ind2
code
(xml:space)

Are the fixed possible options for attributes in MarcXML. With such a limited number of options for attributes isn't it possible to recognise them straight as attributes as it is already done for most of them?

@blackwinter
Copy link
Member Author

blackwinter commented Oct 5, 2021

But is there such a difference between the other attributes and the recordAttributes?

Well, yes, there is a difference: All the other attributes are implementation details, so to speak. You don't pass a literal with name="tag" to produce a datafield with that tag attribute. Instead, the literal (or entity) name is disassembled into the appropriate attribute values. Same for all the others. Except for type.

@blackwinter
Copy link
Member Author

May be superseded by #405.

@dr0i
Copy link
Member

dr0i commented Oct 7, 2021

Superseded by #405, closing this one.

@dr0i dr0i closed this Oct 7, 2021
@dr0i dr0i deleted the 402-encodeMarcXmlAttributes branch October 7, 2021 12:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Marc-XML-encoder: record-type written as controlfield not as attribut of record-field
3 participants