| Re: XSD design patterns (was: Re: railML 3.x: Data Modelling Patterns) [message #2087 is a reply to message #2083] |
Fri, 11 January 2019 17:01   |
Christian Rößiger
Messages: 62
Registered: March 2015
|
Member |
|
|
Hello, Thomas,
thank you for clarifying which use cases can be implemented with global elements. In particular, I see potential for transferring updates for individual elements instead of the entire railML document. The support of this use case is also within the railML-TT developers a goal for a future railML3-TT.
Christian Rahmig's design principle of keeping the XSD structure as flat as possible in order to transfer subsets of elements without unnecessary ballast goes in the same direction. I see global elements as design principle as a more consistent solution to this problem.
From my point of view, the greater flexibility in reusing the schema and the fact that railML3 apparently already follows the pattern "Garden of Eden" more than "Venetian Blind" (in contrast to railML2.x) speak in favor of a consequnt adaptation of railML3 to the design pattern "Garden of Eden".
The (subjectively) better comprehensibility of the "Venetian Blind" pattern speaks against this. In addition, as a developer of railML interface software, I do not (yet) see any need for the transfer of subsets of the railML schema, all our current applications are based on the transfer of complete railML files.
Best regards
Christian Rößiger
--
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
|
|
|
|
Members
Search
Help
Login
Home
