Home » railML newsgroups » railML.infrastructure » railML 2.3 infrastructure extension proposal - "change" (a new attribute "change")
railML 2.3 infrastructure extension proposal - "change" [message #1633] Thu, 31 August 2017 13:02 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
For the use case "capacity planning" we need to define workflow states that are not fixed in time but in a work flow.
Sometimes changes to elements must be made visible. This can either be made through two files and creating a delta or by declaring the changes in the new suggested attribute @nor:change that can be placed under any element.
Enumeration values:
"none": No changes to the model from its last state
"new": a new element has been added to the model
"modified": values if an existing element have been changed
"deleted": an element has been removed from the model

If no change values is defined the default value is "none".

This feature is usually used in the signalling workflow with the colours:
New = green
Modified = blue
Deleted = red
None (everything else) = black

Placing the new attribute nor:change
Changes are placed on the elements that have a change. For changes that span an entire track the change is placed on the track and all elements on the track inherit the change. For changes that span more than one ocp the change is placed on the infrastructure element.
Re: railML 2.3 infrastructure extension proposal - "change" [message #1635 is a reply to message #1633] Fri, 01 September 2017 15:06 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben,

the change topic is closely linked with your other post about the
states, but let's have a look at the issue in detail:

Am 31.08.2017 um 13:02 schrieb Torben Brand:
> For the use case "capacity planning" we need to define
> workflow states that are not fixed in time but in a work
> flow.
> Sometimes changes to elements must be made visible. This can
> either be made through two files and creating a delta or by
> declaring the changes in the new suggested attribute
> @nor:change that can be placed under any element.
> Enumeration values:
> "none": No changes to the model from its last state "new": a new element
> has been added to the model
> "modified": values if an existing element have been changed
> "deleted": an element has been removed from the model
>
> If no change values is defined the default value is "none".

I conclude that there are three different types of changes and that each
change can be clearly categorized into "new", "modified" and "deleted".
If there are no changes, we don't need to provide a change information.

> This feature is usually used in the signalling workflow with
> the colours:
> New = green
> Modified = blue
> Deleted = red
> None (everything else) = black

The colors may be different in other countries (e.g. in Germany), but
the general idea is the same: to see at first sight what has been changed.

> Placing the new attribute nor:change
> Changes are placed on the elements that have a change. For
> changes that span an entire track the change is placed on
> the track and all elements on the track inherit the change.
> For changes that span more than one ocp the change is placed
> on the infrastructure element.

I see a main challenge in using an attribute instead of a sub element,
because the attribute limits the information down to one value (the
element is "new", has been "modified", or "deleted"). A sub element
would allow for a more complex approach, e.g. referencing the date when
the element has been deleted. Further, the sub element <change> could be
linked to specific parts of a <track> using @from and @to position
attributes. Especially for long tracks, this spatial limitation of
changes may help reading systems to be more specific in visualizing
changes on the map.

Another advantage of having a <change> sub element instead of an
attribute: you principally will be able to provide further information
that allow a referencing between infrastructure elements from before and
after the change. So far, your approach is only able to tell you "this
element has been modified", but it is not clear what in detail has been
modified since the original state of the element (before the change) is
unknown.

Dear railML infrastructure power users, what is your opinion on the
topic? Do we need <change> elements and @change attributes within railML
2.4 or are you happy to see such a major concept being implemented with
railML v3? Further, would you like to add more information to the change?

Thank you very much for any feedback!

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: railML 2.3 infrastructure extension proposal - "change" [message #2608 is a reply to message #1635] Fri, 04 December 2020 15:59 Go to previous message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 66
Registered: March 2008
Member
Dear all,

For railML 3, the discussion has been continued in a new thread.

Christian's question about implementing this in railML 2 still remains.

Best regards,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: How to Indicate a working process when doing a signal redesign.
Next Topic: [railML3] speed at level crossing
Goto Forum:
  


Current Time: Thu Mar 28 22:27:47 CET 2024