search

esdscom / sdscom-xml

Schema definition and other documents of eSDScom (formerly SDScom and ESCom), the standard for electronic exchange of Safety Data Sheets in a structured, processible way across Europe and other regions. Please read the wiki for more info. All work is licensed under CC BY-ND 4.0 (https://creativecommons.org/licenses/by-nd/4.0/legalcode)
https://www.esdscom.eu
27 stars 6 forks source link

Introduce separate editing date #181

Closed dirk-qualisys closed 5 years ago

dirk-qualisys commented 6 years ago

Currently, SDScom covers the revision date and the data export date. This is sufficient in an ideal world where the SDS editor creates the SDScom file.

If the recipient or a third party (re-)enters the data however, it is necessary to add an editing data: Let's assume the entered data is imported in a system on a regular basis, e.g. weekly, and an SDSCom set is rejected during import for data errors. How can I detect if, in the next regular data exchange, the data is changed? The export date will be current anyway, and the revision date stays the same because the SDS is the same.

I suggest to introduce EditingDate after IdentificationSubstPrep/VersionNo.

Suter-IK commented 6 years ago

Another approach would be to create a hash code of the sdscom.xml and store it in the importing system after successful import. With such a solution, the EditingDate would be obsolete.

I am not sure, if the field EditingDate is self-explaining enough. I understand it as following: RevisionDate: Date of last relevant/significant changes EditingDate: Date of last change, this might be a significant change or a minor change (e.g. typo correction) Correct?

dirk-qualisys commented 6 years ago

Revision date refers to the document content, editing date to the data processing. In other words: Anything that modifies the printed SDS ("legal document") would change revision date, anything that just modifies the SDScom representation of the legal SDS document would modify editing date.

You are correct that a hash could solve most of the issue because changes are detectable, although and editing date will provide more information. I will think about the necessary scenarios again. Thanks!

dirk-qualisys commented 5 years ago

Here is another real-world scenario when acting as a service provider for supplier SDSs: The customer (= recipient of SDSs from various companies) starts with the service, then later increases the number of fields covered. The service provider cannot enhance all SDSs over night. The EditingDate (when later than the order to enhance all SDSs) allows to differentiate which SDSs are according to the latest order. Any import date or similar has the weakness that it is not accurate, and not part of the data (thus more difficult to archive).

I will introduce the additional field, but certainly make it optional.