Home » railML newsgroups » railml.common » [railML3] Additional Attributes for Revision Management (file management (file-docID, file-version,file content status, file checksum))
Re: [railML3] Additional Attributes for Revision Management [message #2443 is a reply to message #2433] Tue, 19 May 2020 13:30 Go to previous messageGo to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Karl and all others,

I would welcome the suggestions for extending the metadata as suggested by you, Karl.

- I think they should be placed into <metadata> at top level, either in existing DublinCore (DC) data fields or by extensions of DC.
- I see no reason why this should not be allowed in railML 2.x versions, at least from railML 2.4/5. I would welcome it for railML 2.x as well.

However, it would not be a standard if we would not define the meaning/contents and usage of the new fields. The aim of the standard including the new fields should be that two software programs can exchange data without knowing each other.

2.) a new attribute <fileDocumentId>
So, concerning the new attribute @fileVersion, some contents rules should be defined (a file with a higher version number replaces a file with a lower version number etc.).

4.) new attribute <md5checksum>
Concerning the new checksum, I would recommend to exclude it from the railML file at all. Including it brings potential problems in defining which elements should be calculated into in detail (including potential spaces, line breaks etc. before/after?). This makes algorithms to calculate it rather difficult to implement.

Please be aware that railML recommends packing railML files (*.railmlx, see [1]). Therefore, we already have a checksum being part of the standard, albeit not an MD5 (but a CRC32). Better than nothing and should already allow recognising "arbitrary" data transfer errors. Which further use would an MD5 bring? Surely not a safety against deliberately manipulating the railML file because that could easily include the MD5.

However, if an MD5 shall be made part of the standard, I would prefer seeing it in one of the ZIP File Format Specification fields. This at least allows them to include all the railML file itself and being easily calculated and checked.

With best regards,
Dirk.

[1] https://wiki2.railml.org/index.php?title=Dev:fileConventions #Compressed_railML.C2.AE_files
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Problems with changed schemaLocation (http -> https) for Dublin-Core schema
Next Topic: [railML2] extend the elements under <organisationalUnits> with the <designator> element
Goto Forum:
  


Current Time: Wed Apr 17 01:42:58 CEST 2024