encode-marcxml should output leader as first element, all controlfield after that and then all datafields after that

[TobiasNx]

With the last release encode-marcxml outputs the leader as last element, it should be the first. See: https://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd

<xsd:complexType name="recordType" id="record.ct">
<xsd:sequence minOccurs="0">
<xsd:element name="leader" type="leaderFieldType"/>
<xsd:element name="controlfield" type="controlFieldType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="datafield" type="dataFieldType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="type" type="recordTypeType" use="optional"/>
<xsd:attribute name="id" type="idDataType" use="optional"/>
</xsd:complexType>

[TobiasNx]

Idea for tests

With and without 'ensureCorrectMarc21Xml="true"'

https://test.metafacture.org/playground/?flux=%22https%3A//raw.githubusercontent.com/metafacture/metafacture-core/master/metafacture-runner/src/main/dist/examples/read/marc21/10.marc21%22%0A%7C+open-http%0A%7C+as-lines%0A%7C+decode-marc21%0A%7C+encode-marcxml%28ensureCorrectMarc21Xml%3D%22true%22%29%0A%7C+print%0A%3B

https://test.metafacture.org/playground/?flux=%22https%3A//d-nb.info/1106253078/about/marcxml%22%0A%7C+open-http%28accept%3D%22application/xml%22%29%0A%7C+decode-xml%0A%7C+handle-marcxml%0A%7C+encode-marcxml%0A%7C+print%0A%3B

And out oersi scenario. And perhaps some kind of manipulation of existing marc records.

[dr0i]

I get that the marc:leader has to be the first element and implemented that in #549. I don't get your second comment "Idea for tests", though. Especially, the marc:leader has just always to be emitted first - which it does with #549 , regardless of the setting of ensureCorrectMarc21Xml="true".

[dr0i]

Have a look @TobiasNx after your vacation.

[dr0i]

Did the functional review together with @maipet . Looks good, structurally, but indentation is not pretty. As this is merely an aesthetic thing we will build the new release upon this. Opened https://github.com/metafacture/metafacture-core/issues/550.

[dr0i]

Nothing to do here. Closing.

[TobiasNx]

test.metafacture.org/playground?flux=%22https%3A//d-nb.info/1106253078/about/marcxml%22%0A%7C+open-http%28accept%3D%22application/xml%22%29%0A%7C+decode-xml%0A%7C+handle-marcxml%0A%7C+encode-marcxml%0A%7C+print%0A%3B

This scenario outputs the leader wrong as part of the record tag.

IS: <marc:record t<marc:leader>00000naa a2200000uc 4500</marc:leader>ype="Bibliographic">

SHOULD BE:

<marc:record type="Bibliographic">
    <marc:leader>00000naa a2200000uc 4500</marc:leader>

PS: https://test.metafacture.org/playground/?flux=%22https%3A//d-nb.info/1106253078/about/marcxml%22%0A%7C+open-http%28accept%3D%22application/xml%22%29%0A%7C+decode-xml%0A%7C+handle-marcxml%0A%7C+encode-yaml%0A%7C+print%0A%3B

It seems that type is its own top-level element coming out of handle-marcxml

---
type: "Bibliographic"
leader: "00000naa a2200000uc 4500"

[TobiasNx]

An additional note while the position of the leader element is fixed (with minor error when a type statement is given)

This ticket should have suggested that the orders matters not only with the leader but with the data and control fields too:

within the record tag: ``` ... ... ... ... ... ... ... ... ... ``` Data and controlfields should not be mixed. The general order should be `leader`, then ALL `controllfield`s, then all `datafield`s to create valid marc xml.

[dr0i]

In part fixed with #558. Other than discussed at our meeting today I pledge for opening a new issue re. https://github.com/metafacture/metafacture-core/issues/548#issuecomment-2352333717. There should be a link to a playground example that shows the problem. Could you do that @TobiasNx ?