Can MarcXmlHandler drop namespace guard for record elements?

[blackwinter]

Records are only recognized if the element's tag name equals record and the element's namespace URI equals http://www.loc.gov/MARC21/slim. However, at least Alma produces MARCXML without any namespace (xmlns), which MarcXmlHandler cannot process. There's no apparent workaround short of manipulating the XML files before processing.

Seeing as the record element is the only element that is restricted by namespace, it's unclear why this check was introduced in the first place (the commit doesn't provide any clues). All tests pass without it.

[dr0i]

@blackwinter feel encouraged to improve it !

[dr0i]

Thx a lot! It will be part of the new release.

[blackwinter]

Great, thanks :)

[TobiasNx]

This came up in a conversation with hbz/Verbundgruppe. The want to use the cli tool and want a workflow usable for records with as well without namespace. They also do not want to adjust the workflow for every data provider.

handle-marcxml(namespace="") seems to work if a namespace is not provided

But it does not with records with namespaces.

@blackwinter am I missing something. Your commit seems to suggest that this is somehow possible.

[blackwinter]

I'm sorry, I don't understand. Where does your second example include records with namespaces?

[TobiasNx]

Thanks, I updated the link. Here is the example with namespace too.

[blackwinter]

So you mean that you can't use namespace="" with both records with and without namespace? That's where namespace=null comes in, but Flux does not support specifying null values.

[TobiasNx]

So you mean that you can't use namespace="" with both records with and without namespace? That's where namespace=null comes in, but Flux does not support specifying null values.

Correct. We need to decide how to support this. Should I open a ticket to support this? Or is it a better idea to introduce an boolean-option that turns this test off?

[blackwinter]

IDK. The first option would be a general improvement with potentially more widespread applicability, while the second would be a limited enhancement for this particular handler (and also redundant from an API perspective). So I guess I'm leaning towards the former, but I have no idea how difficult it would be to implement.