Home » railML newsgroups » railml.misc » railML 3.x: Data Modelling Patterns
|railML 3.x: Data Modelling Patterns [message #1797]
||Fri, 18 May 2018 09:01
Registered: January 2016
upcoming new major version railML 3.x will contain lot of modifications
and changes. In order to keep a unified layout and model structure, some
elementary "Data Modelling Patterns" have been defined. These patterns
shall represent a set of rules for modellers (and users) how certain
things are being structured in the model. You can find a first version
of these "Data Modelling Patterns" in .
I would like to get your feedback on this approach: Do you agree with
the overall concept of having Data Modelling Patterns? What do you think
about the different patterns in particular?
Any reaction is highly appreciated...
 file replaced by newer version on August 17th, 2018
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
[Updated on: Fri, 17 August 2018 17:02] by Moderator
Report message to a moderator
|Re: railML 3.x: Data Modelling Patterns [message #2011 is a reply to message #1915]
||Wed, 14 November 2018 16:05
Registered: March 2015
In anticipation of the next TT developer meeting I have dealt with the
above document and would like to document the points relevant to me in
Christian, please don't see it as a negative comment ;-), with all not
mentioned points I agree and I generally welcome that there are defined
I see a general problem: The TT data cannot be easily classified into
microscopic or macroscopic. This is probably due to the fact that the TT
objects are not hierarchically composed, but rather networked on the
same level (m:n relations). Example: I have the option to specify a
departure time to the minute or to the second or to omit it at
unimportant stations, but from my point of view it is rather a question
of vagueness than of macroscopic / microscopic. In all cases, the same
data type is used (xs:time), which is always processed the same way by
the reading system.
The only obvious differentiation according to microscopic/macroscopic
results from the dependencies to the railML3 infrastructure.
Comments on the individual chapters:
Model hierarchy and inheritance (slides 3-6)
Do the requirements for container elements also apply if the container
is a subelement (part) of another object or only at the top level?
Otherwise I see the requirements already fulfilled in railML2.x-TT:
- There is a general base element tElementWithNameAndId for all TT objects
- Top-level containers contain only elements of type
Element vs. Attributes (Slide 14)
The mere presence of several (countable) attributes is not a criterion
for choosing element vs. attribute. With this reason one could also
model a coordinate (x, y) as a countable attribute with the help of two
elements. More important seems to be the existence of further
information about the respective attribute (validForDirecton="both" in
Unknown information and Default-Values (slide 15/16)
I understand the intended rule to mean that the absence of an attribute
should always be interpreted as an "unknown value" in the future. I
think this rule is too strict and has several disadvantages.
Currently, a missing attribute can have the following meanings:
1) Value unknown
2) Value intentionally absent. Example: arrival / departure (time) for
beginning / ending trains at first / last station
3) Does not apply in context. Example: <stopDescription>.onOff only
makes sense when held commercially, otherwise the meaning is "does not
apply". However, this value does not currently exist for "onOff
4) Static default value is to be used. Example:
<ocpTT>.trainReverse="false" applies in 99% of cases and can therefore
be regarded as the default value.
5) Context-dependent default value must be used. Example:
<stopDescription>.stopOnRequest is implicitly always true for
non-commercial holds and therefore does not have to be explicitly specified.
1) is still allowed
2) and 3) could only be eliminated by changing the modelling. I see
there primarily the replacement of attributes by elements, since a
missing element can still represent both "value unknown" and "value
intentionally not present". It is questionable whether this makes the
schema more understandable.
4) and 5) These actual default values can certainly always be specified
explicitly in the future, but in my opinion this would lead to an insane
enlargement of the files. At least the (more frequent) static default
values (4.) should be preserved.
Boolean information (slide 17)
It seems to me that the case "Mandatory Boolean with true|false as valid
values" is not intended. What is the reason for this limitation?
In general, I would look at boolean values as general attributes and not
define them as a special case. Option 2 therefore contradicts the
statement "Mandatory elements can never be unknown" (slide 15).
In addition, the question arises in which cases a boolean value will be
used in the future and when an enumeration with 2 elements will be used.
In my opinion, this decision has so far been decided more according to
References (slide 21)
As I said before, I still don't have the idea to divide the TT-world
into macroscopic / microspcopic, but so far option 1 is used
(macroscopic refers to microscopic) more frequently, which I still think
makes sense. Example: A <train> references its operating points
(<ocpTT>) and not vice versa.
Multiplicity (slide 24)
I generally agree with the statements, whereby in special cases there
may be container elements with a minimum of 2 elements, e.g. there is
currently a <Path> element with minOccurence="2" in railML2.x.
What is missing from my point of view
Definition of container elements in xml/Uml.
Currently most containers are defined in railML using xs:sequences. Is
there a "ban" on other structuring elements such as "xs:choice" or
"xs:all" or their equivalents in UML by railLM3-IS?
Use of polymorphism
Inheritance of elements is currently already used in the schema, but
rather by defining "template elements" with certain general attributes.
However, there are hardly any cases in TT where the schema requires an
(abstract) base class, and alternatively different classes derived from
it can be used. This would be conceivable, for example, when mapping
hold information with an abstract element <ocpTT> with some common
attributes and derived subclasses <ocpTTPass>, <ocpTTCommercialStop> or
<ocpTTOperationalStop> with additional individual attributes. Is there
any rejection or encouragement on the part of railML3-IS?
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
|Re: railML 3.x: Data Modelling Patterns [message #2026 is a reply to message #1915]
||Tue, 27 November 2018 16:08
Registered: September 2004
I generally agree with the design patterns, as long as we really try to respect them within all railML 3.x domains in order to create a common look and feel for railML.
1) "Hierarchy:" Ok, Container/Object/Parts (or Components) would correspond with trains/train/trainParts. Views could be "commercial trains", "operational trains", "ordered slots", ...
2) "Naming": Ok, so there will be lots of boolean attributes like "isThis" or "hasThat"
3) "Boolean information": Option 1, a dedicated "unknown" should be part of an enumeration together with "assumed", "irrelevant", ...
4) "References": Option 1, because the linking might not be as straight forward as intended. A train could belong to several different kind of train categories.
SMA und Partner AG
Gubelstrasse 28, CH-8050 Zürich
Current Time: Mon Dec 10 17:13:18 CET 2018