search

metafacture / metafacture-core

Core package of the Metafacture tool suite for metadata processing.
https://metafacture.org
Apache License 2.0
72 stars 34 forks source link

Enable ignoring namespace guard for `handle-marcxml` in flux #569

Open TobiasNx opened 2 weeks ago

TobiasNx commented 2 weeks ago

@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 https://github.com/metafacture/metafacture-core/issues/330#issuecomment-2470129392

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

dr0i commented 1 week ago

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 commented 6 days ago

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 commented 6 days ago

... 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 commented 6 days ago

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.