|Re: Sparx Enterprise Architect for TT modelling? [message #1558]
||Sun, 30 April 2017 14:53
Registered: November 2004
thnk you very much and sorry for the late reply. Even discussed in TT
developers meeting this topic is related to all subschemes of railML.
This is why Philip does not mention to answer and I did not see it.
Sorry for that. Please see my answers below:
> 1. I think the "master file(s)" for a public / open format should be software independent, so that everybody can participate without installing extra software. In case of the railML schema, these are the *.xsd files.
Yes, the official format of railML descriptions will be the XSD files as
published for railML 2.x and railML 3α. If whished by the railML.org
community we could publish the UML for railML 3.x as XMI files too.
> 2. All files should by under version control, so that the differences between each version can be diffed without extra software (e.g. online with SVN or GIT)
This we're doing since starting the development of railML 2.0 beginning
from 2008. This software versioning and revision control system (Apache
Subversion) is available under https://svn.railML.org and direct linked
from our website. Openness and equality are one of the basic principles
> 3. Currently, I don't see a real benefit with the "One UML approach". Reason: The only thing I need is a valid *.xsd file from which I can generate code in the preferred programming language like Java, C++, C#... I don't think that it is the job of railML to generate code. This could end up in an infinite number of formats the railML developers have to support.
Yes, it's not the the job of railML.org to generate code for Delphi,
C++, C#, Java or other programming languages. We don't have the
knowlegde and capabilities for such a work currently and this was also
not asked by our railML community.
The "One UML approach" was asked by members of the RailTopoModel Expert
Group of UIC (which are railML.org members too) to ensure the
parallelism between RailTopoModel and railML in the infrastructure
development. We are open to this request as long it is not delay the
requested time plan for railML 3 or hinder us in the implementation of
the agreed use cases for railML 3. For railML 2.x there are no plans for
UML modelling nor "One UML approach" at railML.org.
> 4. It's a little bit risky to use a proprietary software and a toolchain with extra development for generating XSDs and Java code. In this case the whole format depends on the export functionality of Sparx EA and some additional tools.
Even we developing a "open" railway data exchange format we do not want
to start a "Open source versus proprietary software" discussion or flame
war. railML.org will use both types of software, depending from the
usability and results needed for the community.
Due to the wide usage of Sparx EA we do not see a large risk of
discontuniation and major changes, for the "One UML tool" [Working title
only!] we are in discussion with UIC and the RailTopoModel Expert Group
We are open for other tools like Papyrus as open source software for the
modelling of UML but this is currently not the main focus of railML.org.
If we get additional expertise and support we can think over on mid term
> 5. There is also the risk of getting changes in the generated XSD files when updating to new versions of Sparx EA. In the worst case, they must be corrected manually.
Yes, this is true that such a risk exists. But as we will not change the
version of Sparx EA during modelling of one version and we will check
the generated results after every update the risk seems to be low and
acceptable. BTW, the same risk will appear with every other software.
I hope, thies answers will help for the first time, we will discuss
further during the meetings next week in Paris (see & register:
X-Post and Follow up to railML.misc
Vasco Paul Kolmorgen - Governance Coordinator
railML.org (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Am 06.03.2017 um 19:32 schrieb Mićo Mićić:
> Hi together!
> At the last timetable developer telco (2nd March 2017), the
> participants discussed whether the modelling software "Sparx
> Enterprise Architect" and the "One UML approach" could be
> used for the timetable modelling. This is currently being
> tested by the infrastructure community.
> At the moment it is too early to make a decision. For this
> reason, the timetable community will collect all needs and
> concerns in this post so that it can be used as input for
> future developments in the infrastructure part.
> Here my input:
> I think the "master file(s)" for a public / open format
> should be software independent, so that everybody can
> participate without installing extra software. In case of
> the RailML schema, these are the *.xsd files. All files
> should by under version control, so that the differences
> between each version can be diffed without extra software
> (e.g. online with SVN or GIT) Currently, I don't see a real
> benefit with the "One UML approach". Reason: The only thing
> I need is a valid *.xsd file from which I can generate code
> in the preferred programming language like Java, C++, C#...
> I don't think that it is the job of RailML to generate code.
> This could end up in an infinite number of formats the
> RailML developers have to support. It's a little bit risky
> to use a proprietary software and a toolchain with extra
> development for generating XSDs and Java code. In this case
> the whole format depends on the export functionality of
> Sparx EA an some additional tools. There is also the risk of
> getting changes in the generated XSD files when updating to
> new versions of Sparx EA. In the worst case, they must be
> corrected manually.