Home » railML newsgroups » railml.common » railML 3.x: Data Modelling Patterns
Re: railML 3.x: Data Modelling Patterns [message #2015 is a reply to message #2014] Mon, 19 November 2018 12:49 Go to previous messageGo to previous message
Cédric Lavanchy is currently offline  Cédric Lavanchy
Messages: 3
Registered: February 2018
Junior Member
Dear all,

I find a good idea to have some rules how elements have to be modeled. These are rules, but rules are made to be broken. Not in all cases but I can imagine, that at some place, they could be counterproductive. My advise is to tolerate some difference to the rules but it must be justified and known from the community, otherwise it is the open door to any kind of abuse.

Here some specific points:

1) "Inheritance": I have nothing against inheritance except that it is not always correctly use. See the Liskov substitution principle (Square should not inherit from Rectangle)

2) "Common domain": take care to put in there only the required elements and not everything, otherwise it will become impossible to manage

3) "Names of elements and attributes": I heard many times some complains about the size of the files and for instance by the Timetable, effort are made to reduce the amount of date in order to reduce the size of the file. On the other hands, the names can become longer. We have to take care not to ruin some efforts.

4) "Boolean information": option 1 (optional version)

5) "References": option 1 (if they are not sub-elements already)

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [railml3.1] Change "v" to "speed" in attribute names
Next Topic: More standard attributes for objects
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Mon Apr 29 14:43:34 CEST 2024