MarcXmlEncoder ouputs "leader" wrongly

[dr0i]

Reported by @hagbeck, this ouput is wrong:

<marc:controlfield tag="type"></marc:controlfield>
<marc:controlfield tag="leader">00424nam a2200024 c 4500</marc:controlfield>

It's produced opening a MarcXml file, using the following flux:

sourceFile|
open-file|
decode-xml|
handle-marcxml|
morph(morphFile, *)|
encode-marcxml|
write(targetFile);

with this simple '_elseNested' morph:

<?xml version="1.0" encoding="UTF-8"?>
<metamorph xmlns="http://www.culturegraph.org/metamorph"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1" entityMarker=".">
    <rules>
        <data source="_elseNested" />
    </rules>
</metamorph>

@hagbeck : do you know how exactly: the output should look like?

Results from #107.

[hagbeck]

I'm expecting it like

    <marc:record type="...">
        <marc:leader>00424nam a2200024 c 4500</mx:leader>

respectively

    <marc:record>
        <marc:leader>00424nam a2200024 c 4500</mx:leader>

if type is empty or Null.

I've observed another effect.

<marc:datafield tag="856" ind1="4" ind2="0">
   <marc:subfield code="u">http://www.video2brain.com/</mx:subfield>
   <marc:subfield code="x">Agentur</mx:subfield>
</marc:datafield>

results in multiple entities like

<marc:datafield tag="856" ind1="4" ind2="0">
        <marc:subfield code="u">http://www.video2brain.com/</marc:subfield>
</marc:datafield>
<marc:datafield tag="856" ind1="4" ind2="0">
        <marc:subfield code="x">Agentur</marc:subfield>
</marc:datafield>

using the above morph.

[blackwinter]

This issue seems to be threefold:

1. Entity with more than one subfield results in multiple entities; see _elseNested: Entity with more than one subfield results in multiple entities #338.
2. XML attributes are transformed into elements; see XML Attributes and Element values #379.
3. MARC leader results in control field (<marc:controlfield tag="leader"> instead of <marc:leader>).

Part 1 is already solved and part 2 is covered by another issue; so I would propose to only deal with part 3 here (and update the title accordingly).

[blackwinter]

The remaining issue (part 3 above) should be fixed by #401. Could you verify?

[dr0i]

Closed incidentally by #401. Reopening.

[blackwinter]

Closed incidentally

Can you clarify? The pull request was supposed to resolve this issue. If it doesn't, it shouldn't have been merged, right? If it does, though, this issue should be closed by it. What am I not getting?

[dr0i]

Yes, you are right. I violated the definition-of-done by not awaiting the functional review (which should be done by the one assigned to the issue) and merging nonetheless (I saw your tests and passed this as functional review for myself, but that is not our agreed convention).
Then I reopened the issue to get a functional review or an OK by the reporter. Will ask @TobiasNx who shall do the functional review.

[blackwinter]

Okay, makes sense. Thank you.

[TobiasNx]

Leader seem right now:
<marc:leader>00000pam a2200000 c 4500</marc:leader>

+1

But the type-attribute refrence that @hagbeck mentioned still needs to be fixed. opened a new ticket:
#402

Also @dr0i and I were confused that there are two version of marc-xml, one with namespaces and one without. The version without seems to be more common. Both seem to be valid. We thought that an option for the output would be nice #403

[blackwinter]

But the type-attribute refrence that @hagbeck mentioned still needs to be fixed.

For future reference I'll repeat it here: In order for the (MARC) XML encoder to recognize an attribute, the decoder (or the morph) has to mark it as such (xmlHandler.setAttributeMarker("~") or handle-marcxml(attributeMarker="~")).

EDIT: MARC XML encoder doesn't know to handle marked literals as attributes, only simple XML encoder does (see #394).

[dr0i]

Updated also i.a. https://github.com/metafacture/metafacture-documentation/blob/master/flux-commands.md#handle-marcxml (which I frequently use to look up usage and also unfortunately frequently forget to update if something in metafacture-core is updated ... would be nice if we could update that flux-commands.properties when pushing something to master in metafacture-core).
But, admittedly, even the updated flux-commands.properties doesn't help much on how this works exactly (e.g. no mention of setting attributemarker to ~ in handle-marcxml and how/why this makes the encode-xml to write <record type="Bibliographic">.

More important, as you noted @blackwinter, we need the proper handling in encode-marcxml.

[blackwinter]

would be nice if we could update that flux-commands.properties when pushing something to master in metafacture-core

Do you mean flux-commands.md? That would be #368 then, right?

[blackwinter]

BTW: I still think this issue could have kept its focus on leader; for type we have #402 now.

[dr0i]

Re flux-commands.md: ups, yes indeed - wasn't aware of #368!
Re title: ack (noticed in #336 (comment) the report of type - but I agree that the title of the issue is important and sets the focus - and yes we have #402 now). Going to revert the title.
So we could close this issue here @TobiasNx ?

[TobiasNx]

yes, leader is put out properly.