Optionally encode marked literals as MARC record attributes.

[blackwinter]

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

Fixes #402.

[blackwinter]

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]

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]

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]

May be superseded by #405.

[dr0i]

Superseded by #405, closing this one.