| Re: [railML3] Extension methods [message #2970 is a reply to message #2861] |
Fri, 18 March 2022 16:09   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear coordinators,
since you did ask for, I want to give you an explicit reply on this topic. All in all, we do not have objections against the 'new' (more explicit) approach on extensions, otherwise we would have objected when Thomas wrote about it. But I must confess I am also not happy about that.
I welcome the advantage to be able to explicitly define the place (target element) of the extension. The advantage of clearness and less misunderstanding surely outweighs the possible disadvantages (the need to repeat it for each instance).
I am not happy about the raised complexity, difficulty and formalism which comes along with this. We already see a raising "access barrier" against railML because of its raising complexity especially for "outsiders". Extensions are at least a bit a cure against such concerns. If extensions will now become also more complex and difficult to use by "polymorphism" (to express it rather friendly) or "hack-casting of elements" (to express it rather conservative), we fear that concerns against railML in general will raise even more.
However, as I wrote before: All in all, we do not want to veto. RailML is already so much complex that you can probably only use it if you are a railway-maniac and a computer-freak the same time so that the increase in complexity may be regarded as relatively low.
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
