IIDM Versionning - questions
|
VEDELAGO Miora
Hi all,
As you may know, we are currently working on the versionning of XIIDM.
In this context, the main question we have is: do we need to handle the serialization of different versions? At first, we wanted to be able to read/validate older versions but only write in the latest (i.e. current) version. However, this will bring a lot of restrictions in processing XIIDM files. Should we allow to serialize in older versions?
If the answer is yes, here are our proposition:
During export, the responsability to check compatibility between the version the user wants to write in and the network itself (i.e. to check if every component of the network can be serialized in the given version) is on the serializers of the network
components.
If a new equipment is added in version N, the user will only be able to serialize it in version N and newer (N+1, N+2...). If they try to serialize a network containing this equipment in older versions, an exception will be thrown by the equipment's serializer.
If a new optional attribute is added to an equipment in version N, this equipment will be serializable in older versions (N-1, N-2...) if and only if this attribute has its default value. If its value is not the default value, an exception will be thrown
by the equipment's serializer if serialization in older versions is attempted.
If a new required attribute is added to an equipment in version N, an exception will be thrown by the equipment's serializer if serialization in older versions is attempted.
Some extensions are dependent on XIIDM (e.g. CurrentLimitsPerSeason depends on CurrentLimits modelisation in XIIDM). Hence, extensions should be versionned as well.
Some specific examples:
Is it clear for you? Do you think writing in older versions should be an implemented feature? If you do, do you agree with our propositions? Have you something to add to them? If you don't, how should we handle old versions files in your opinion? Don't
hesitate to describe specific use cases to press your point.
Miora RALAMBOTIANA
CHARGE DE PROJETS MAINTENANCE EXPLOITATION SI PES
- Direction Système d'information et Télécom - Département Développement Logiciel - Système électrique
miora.ralambotiana@...rte-france.com "Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction. This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message." |
|
|
|
MURGEY Sebastien
Hi all,
On my side, I do not think the benefits of being able to do that kind of backward conversion are worth the complexity of the associated development. I do not have any critical use case for this feature. In case we decide to do that development, I agree with the proposition. Sébastien |
|
|
|
BAGUE Mathieu
Hi Sebastien, all,
When Miora and I thought to the backward compatibility, we considered an architecture with 3 systems that exchange networks, but with a cyclic dependency. How do you update IIDM API (or XML converter implementation) in that case? You have to be able to update each component independently but with a strong bond to the IIDM format, you cannot and it will be necessary to update all components in the same time. I think the problem also occurs if the networks are stored in a shared database. Best, Mathieu |
|
|
|
MURGEY Sebastien
I think there are organisational ways to solve this type of issues. However, I understand the use case shared.
It also largely depends on the rythm of breaking changes creation in IIDM. If every two months we have to align ourselves on our releases because of IIDM XML export breaking changes, this issue will be far more important than if it is only once a year... |
|
|
|
LECLERC Sylvain
Hi all,
1) Unfortunately I think the use case is important. If we don’t have this feature, if one application provides IIDM data to other applications and if that first application wants to use new features of powsybl (and hence a new IIDM format), it will have to wait for all client applications to have migrated to that version of powsybl and deployed a new version. This may have strong impacts on deployment schedules in our IT systems, and does not seem acceptable.
2) About the proposal, I am OK with most of it, but I would propose to relax the requirements on new attributes: if a new attribute is not required by the version 1, I think in most cases it should not throw when serializing to that version, even if the attribute is required in version 2. Maybe this should be decided on a case-by-case basis : for some new attributes, the network will still make sense without them, maybe with some adaptation (like transferring it to an older attributes), while for others it will not.
Best regards, Sylvain
De : powsybl-tsc@... [mailto:powsybl-tsc@...]
De la part de MURGEY Sebastien via Lists.Lfenergy.Org
I think there are organisational ways to solve this type of issues. However, I understand the use case shared. "Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction. This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message." |
|
|
|
VEDELAGO Miora
Hi,
Rather than throwing an exception when trying to serialize an IIDM network in a uncompatible previous version, it has been proposed to use network's extensions to serialize it as accurately as possible and keep new information in extensions (compatible with the previous version). I am not really sure about this workaround, what do you think? Miora |
|
|
|
JAMGOTCHIAN Geoffroy
Hi,
What was the initial issue? If it was to be able to generate old IIDM data for out dated applications (so not supporting last IIDM standard) it won’t work at all as XIIDM will be different/incompatible and not loadable.
Geoffroy
De : powsybl-tsc@... [mailto:powsybl-tsc@...]
De la part de RALAMBOTIANA Miora via Lists.Lfenergy.Org
Hi, "Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction. This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message." |
|
|