Use the UnterstuetzteSEPADatenformateTrait in all Actions to avoid xml namespace missmatches

[ampaze]

Banks can report sepa xml namespaces as filenames like sepade:xsd*.xsd instead of urn:iso:std:iso:20022:tech:xsd:* this uses the existing trait that converts these namespaces in all actions that check xml namespaces.

[ampaze]

I am currently testing these changes with our banks, but am open for reviews.

[Philipp91]

It's a little odd that we have both spelling variants. Renaming one of them would be a breaking change, but I think we should still do it. Not only would that get rid of the weird fallback here, but it would also make the library's API more consistent for users.

I don't use this API myself, so I don't know whether typical users of this API would have ->unterstuetzteSEPADatenformate in their code. Though I suspect that accessing that field directly isn't generally necessary to use this API. What do you think?

[ampaze]

I also think we should change it to be consistent, but didn't want to break anything. Thinking about it further, I doubt that people are using ->unterstuetzteSepaDatenformate in their own code.

As the spec uses 'SEPA' (and not 'Sepa'), changing $unterstuetzteSepaDatenformate to $unterstuetzteSEPADatenformate should do to the trick.

[leobeal]

" I doubt that people are using x" - famous last words. :)

I would suggest any breaking change to be released in a v4.

[Philipp91]

@nemiah Is it easy to do v4? Are there release notes anywhere? Or is there a branch where we can store changes to enter the next breaking release?

It's surprising to me that this would be the first breaking change since v3 five (!) years ago. Maybe this library has a different policy for mildly breaking changes.

[Philipp91]

As the spec uses 'SEPA' (and not 'Sepa')

While I'm not against using "SEPA" instead of "Sepa", the spec doesn't make for a relevant argument here. It's written as prose text, where acronyms are fully capitalized, of course. But here we have a camel-case identifier, where the general opinion out there is to treat acronyms like any other words, i.e. without internal capitalization. There's only some side discussions whether this should also apply to very short acronyms or not.

(((One argument I hear often is that transformation to e.g. snake case should be mechanical. So if we want unterstuetzte_sepa_datenformate and not unterstuetzte_s_e_p_a_datenformate, then the camel case must be unterstuetzteSepaDatenformate, or a typically dumb IDE would make mistakes when transforming automatically. Another argument is that lower-camel-case is otherwise tricky, e.g. should it be sEPAFoo or sepaFoo or sePAFoo. Personally, I don't give these arguments much weight because to a human it's clear what to do in each case; but I still see these cases as an indicator for what's the most proper solution if given no other signal.)))

That said, this library is currently not consistent at all: phpFinTS is the repo name, FinTs is the main class name. In terms of acronyms coming straight from the spec, MT940, segment classes like HITAN and BPD are all-caps, whereas Deg, Kti, Iban and such are not.

So while we can't realistically achieve total consistency across all identifiers in the library, if we want to make unterstuetzteS???Datenformate consistent, we should loook at how SEPA is typically spelled elsewhere in this library, to be self-consistent at least. (And ignore the spec.)

Some quick grepping shows that SEPA currently has the majority. So I'd err on that side to achieve eventual consistency. Another option (if we want to side-step the breaking change) is to punt on this for now (leave as is, non-breaking) and send a separate commit to a new v4 branch that fixes this plus the few remaining Sepa cases.

[ampaze]

You are correct with all your observations. I have no preferences how the names should be.
Right now I would just leave it handling both cases and maybe revisit the problem in a larger context, making everything more consistent.

[ampaze]

I have not had any errors with this so far.