Enable ignoring namespace guard for handle-marcxml in flux

[TobiasNx]

@blackwinter introduced the possibility to turn off the namespace guard with handle-marcxml but at the moment it only works in Java due to setting the option namespace=null. Assining null is not possible in FLUX.

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?

Originally posted by @TobiasNx in #330 (comment)

hbz/Verbundgruppe has the usecase to use the same workflow for transformation marcxml WITH and WITHOUT namespace. This would require this enhancement.

[dr0i]

Value "null" is no valid URI anyway, and from user perspective it's easier to simply always assigning anything as a String ("").
@blackwinter please explain why we don't want to just allow namespace="null" to behave like setNamespace(null).

[blackwinter]

Are you saying that we should derive meaning from an opaque string just because of limitations in the grammar specification? Are you also saying that it should only apply to the MarcXmlHandler in this specific instance, not to Flux in general?

In that case, I would very much prefer to introduce another option to disable the namespace check (boolean). I probably shouldn't have done it this way to begin with.

[dr0i]

... limitations in the grammar specification?

At this point I see them as guardrails.
Just setting something to null is not self-explaining. So we would have to document what the semantics of null would be, anyway.

In that case, I would very much prefer to introduce another option to disable the namespace check (boolean).

I vote for this.

I probably shouldn't have done it this way to begin with.

As your implementation is useful only to programmers I think they will cope with it. But of course it would have been the best to implement something that can be also used by flux.

[blackwinter]

I'm sorry, but I don't follow this line of argument. You would still need to document what "null" means in this context. I, for one, really think that Flux should support other (primitive) data types as well; I've been bothered by "true" or "42" whenever I had to write it just to satisfy the grammar. You lose out on expressiveness. Then again, I don't use Flux that often, so I can't really complain. If you think that the limitation to strings makes it easier in teaching and support, I'll accept your word for it.

[TobiasNx]

Should I test this feature?

[dr0i]

Yeah - you can give it a test. I thought this functionality too simple to need a functional review but it doesn't hurt of course.