| Re: [railML3] Additional Attributes for Revision Management [message #2455 is a reply to message #2433] |
Fri, 05 June 2020 18:13   |
Michael Gruschwitz
Messages: 11
Registered: May 2020
|
Junior Member |
|
|
Dear Mr. Jerosch, dear all,
let me first introduce myself: My name is Michael Gruschwitz and I will
strengthen the team at Bahnkonzept in the railway IT area. At the moment
I'm working on different projects and hope to be able to contribute and
get help in railML matters in the future too.
Am 13.05.2020 um 16:25 schrieb Karl-Friedemann Jerosch:
> To improve the practical use of railML files as data
> exchange file,
> the work group "ETCS Track Net" suggests to add the
> following 4 information to be implemented in railML 3.2:
I think it's a good idea that when writing and reading our
infrastructure data, it provides additional information that we
previously had to maintain manually. We would very much welcome it if
this information were included in railML 2.5 and from railML 3.2 onwards.
> 1.) a new attribute <status> providing information of the
> quality status of a railML file with a closed value list:
> draft/verified/released
>
> Note: This attribute could be part of e.g. <metadata>.
Agreed. But I would suggest to structure the information a bit more
finely, because I think there will be more levels.
What about @status with:
- stub: data which is only partial filled/incomplete
- internal: data which is complete, but not internal checked and not
released to a third party
- draft: data which is complete, internal checked and therefore
released to a third party
- verified: data which is complete, internal checked and crosschecked
by a third party
- ....
But I assume that there are certainly already some standards or process
descriptions for this, so that we do not have to reinvent the wheel.
Can railML check this?
> 2.) a new attribute <fileDocumentId> providing information
> of the document id of the railML file (as substitution
> group="any"):
> e.g. "ID123467890-LineX-Station1/Station2-XYZrailways"
Sounds good, but I think that the "talking ID's" will get no mercy from
the railML coordinators.
> 3.) a new attribute <fileVersion> providing the file version
> number of a railML file with values:
> 00.00, ..., 99.99
Fine with me, but should really only these kind of numbers be allowed?
What about "Alpha", "version 10.10 Yosemite", "version 10.14 Mojave", ...?
> 4.) a new attribute <md5checksum> containing a checksum over
> all following file contents covering (at least) <common>, <infrastructure>,
> <interlocking>, <rollingstock> and <timetable> (if exisiting
> in the railML file),
> and if possible also as many elements of <metadata>.
Even if we don't use it at the moment and therefore don't need it, it
would be a useful extension for the future.
Best regards,
--
Michael Gruschwitz
Bahnkonzept Dresden/Germany
|
|
|
|
Members
Search
Help
Login
Home
