Use XML rather than pythonic style attribute names

[nigelm]

This is currently a discussion of a proposal which may, or may not be carried forward

When the python version of broadworks_ocip was first put together I made the decision to use, what I see as, pythonic naming for things. So attributes are snake case - ie user_name - whereas the wire protocol uses Java naming conventions - userName. Classes are Camel case - eg AuthenticationRequest - this matches the Broadworks/Java naming style.

This makes things more complicated when building commands based on Broadworks documentation since all the attributes need converting to a different naming convention.

In hindsight I think the original decision was probably a mistake, and I should have gone with naming consistant to that used in Broadworks throughout. However that was a couple of years back, and there are people using the code as is.

There are four possible solutions to this:-

Keep The Status Quo

Don't change a thing, people can live with the pythonic style naming

Convert Attributes to XML/Broadworks Naming

• All attributes naming is changed to the Java style
• All existing code needs changing to match, so all current consumer programs are broken
• The internal code is made simpler, since there is no transformation of names

Convert Attributes to XML/Broadworks Naming with Aliasing

This would leverage aliases between the pythonic snake case and the Java style attributes, using the facilities shown in https://adamj.eu/tech/2021/10/13/how-to-create-a-transparent-attribute-alias-in-python/

• All attributes naming is changed to the Java style , but you can use pythonic style as well
• existing code should work
• The internal code loses the additional mapping entry in the element table, since there is no transformation of names, but
• there will be more generated code to support the aliases

Add XML/Broadworks attribute naming with Aliasing

As the previous example, except the primary mechanism is pythonic snake case naming

• Basically all the pros/cons of previous proposal except a bit more complicated.
• Do not lose the code handling transformation of names

[karol-skibinski]

My opinion of these solutions: Aliasing - sounds good ;-)

[kikohnl]

My preference would be Convert without Aliasing. More work for us, but simplifies the code base for you!