Home » railML newsgroups » railML.infrastructure » [raillML3] Revision of rulebook (Proposal for new attribute in <typeDesignator>)
[raillML3] Revision of rulebook [message #3178] Tue, 19 December 2023 12:37 Go to next message
Georg Boasson is currently offline  Georg Boasson
Messages: 18
Registered: October 2020
Junior Member
The rulebook which is the referenced register in <typeDesignator> may be updated with new revisions. A new revision of the rulebook may change the content or meaning of an entry and therefore a reference to the revision of the rulebook is necessary.

The @revision attribute may be an optional text-string in addition to the attributes: rulebook, entry, and description.

Proposed additional attribute for <typeDesignator>:

revision: The revision of the rulebook (optional; xs:string)


An extension of the @rulecode attribute might be considered for railML2.
Re: [raillML3] Revision of rulebook [message #3179 is a reply to message #3178] Fri, 22 December 2023 16:46 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 68
Registered: March 2008
Member
Hi Georg,

Normally, such changes are avoided in rulebooks, as they can cause safety-critical confusion. If there are significant changes, it may be more relevant to consider it a new rulebook, with a different code. Do you have any relevant examples?

Best regards,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [raillML3] Revision of rulebook [message #3184 is a reply to message #3179] Fri, 05 January 2024 13:44 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Georg,

I agree with Thomas that major changes in the meaning of a rulebook entry should not occur without a changed rulebook register name.

However, the topic of versions, revisions etc. of registers and external documents will become relevant at other situations, too. Therefore, a general approach on how the schema can deal with these revisions and versions of external resources (not only in infrastructure, but maybe also in rollingstock or timetable) may be useful for future railML versions.

Any ideas or comments from the community?

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: Missing attributes and maybe elements in railML3.2 for RTCI-a
Next Topic: [railML3] Road traffic signals
Goto Forum:
  


Current Time: Sat Apr 27 18:20:57 CEST 2024