-
Notifications
You must be signed in to change notification settings - Fork 6
Home
This is currently a collection of items that have no proper place in the schema files themselves or on the eSDScom web site. Subpages are not linked - see list on the right!
Everybody is invited to benefit from and participate in SDScom. Really everybody, no matter if you have a chemical, technical of other background - just post your issue. While this is part of SDScom being "open", the project steering groups encourages you to talk to some specialists before posting in case you feel something is wrong or missing but are not sure why. These project pages and issues are maintained by active contributors in their spare time and cannot be used to replace REACH or CLP training. If they reject a request, they do not mean to be impolite but may not find enough time to explain scientific or regulatory reasons in full detail in every case.
The main SDScom file is called SDSComXML.xsd. It uses SDSComXMLCT.xsd for complex types and SDSComXMLDT.xsd for simple document types. Since just the various GHS types require many different type definitions (both simple and complex), all GHS types are collected in SDSComXMLDT_GHS.xsd. All types specific to certain legal areas are defined in SDSComXMLNE_ZZ.xsd, with ZZ being the two letter ISO country code for the specific region.
The root element of any SDScom file is <DatasheetFeed>, defined at the very bottom of SDSComXML.xsd. It contains administrative information on the file in <InformationFromExportingSystem> and then a sequence of <Datasheet> - the name has historical reasons and should rather be "Product" today, because every instance can cover multiple (regional) SDSs for the same product.
The next level of nodes represents the sixteen sections of an SDS (plus for the EU, the annexes). If you understand safety data sheets, you will easily find content in SDScom. These sections are defined as separate types in SDScom.xsd. The idea of SDScom is that you can print a full safety data sheet from any complete SDScom file just with a stylesheet (CSS) for proper formatting, thus some information is redundant and may be omitted during import, such as the list of H phrases in section 16 which is compiled from the phrases used in sections 2 and 3.
The main deviation from SDScom's paradigm to use the printable SDS as a template for the XML structure are components. In various parts of and SDS, information on ingredients is used. To facilitate a proper assignment of all such info to the prropriate chemical substance, all of this info is bundled in the type Component.
SDScom tries to enforce valid data as good as possible, while being as simple as instructive for implementation as it could be. Thus, certain rules have shown to be helpful:
- Most fields are optional. Users and IT systems are encouraged to fill the format only partially - some electronic data is far better than no electronic data.
- Enumerations are widely used as they are easy to understand. But they are to be avoided where values are very volatile, such as German GISCODEs.
Development of SDScom is coordinated with EuPhraC phrases, but SDScom can be used with any phrase catalogue, or with multiple, or even without any. In any case you should provide the full text of any phrases used so that the XML file can be consumed by systems that use other phrase catalogues. Often, SDScom files are prepared using a standard phrase catalogue such as EuPhrac (or whatever your software vendor provides) plus an individual phrase catalogue to cover non-standard content.
Instances of DatasheetFeed/Datasheet/InformationFromExportingSystem/PhraseCatalogue specify the catalogue used for the file. It contains an attribute \<PhraseCatalogueId\> which is used in every field instance of the type Phrase to specify which of the listed phrase catalogues is used. The string fields in \<PhraseCatalogue\> are not standardized, i.e. there is no officially maintained reference list of phrase catalogues. Just be clear and precise when exporting, so that human readers can pick their importing catalogue sensibly.
Importing systems often have tools to match phrases from other systems to their own phrase catalogue. A match once defined is stored for future data imports, so that imports will require only few manual interventions after a short training period. If you can't find a match, the software will import the phrase text into your own user phrase catalogue to facilitate translations and future access.
The SDScom implementation of phrase is very powerful and meant to be the superset of all phrase features in the market - it allows for various parameters in arbitrary places. Most IT systems will not support all of its features, but every feature is supported by at least one system. Because lost information can't be recovered, use phrases upon exporting with as much features as your system allows (and post an issue, if your system allows more). On importing, adapt to your system features, for example create compile user phrases from SDScom phrases and their parameters if your system can't use parameters.
In general, the content of every node which is not self-explanatory should be documented in annotations. Other than such "documentation" annotations, there are two "appinfo" annotiations for fields that are part of defined SDScom subsets called "SDScomBau" or "SDScomChem" (a superset of "SDScomBau"). Both subsets origin from a German implementation project called "SDBtransfer" which showed that even those subsets will be sufficient for many industry applications. With "SDScomChem" fields, you are able to implement basically everything except printing the safety data sheet itself. Thus, it is a good idea to implement SDScomBau first, then expand the field set along user requests.
If you are missing clarification on specific fields, or if you are missing an appropriate place for certain content, don't hesitate to post an issue here (preferred) or ask for support via email to the release manager. Support is free!
The current branch of SDScom uses a product-based paradigm to support data exchange between different IT systems. ERP (Enterprise Resource Planning) systems such as SAP usually maintain a product with links to n SDS flavours, or in other words, all info that is the same for all national versions of an SDS is represented only once. So the root element, for historic reasons still named "DatasheetFeed", covers a list of "Datasheet"s, which cover all information for a specific manufacturing product for all markets, including but not limited to different sales product names, article numbers, classifications and composition lists for the safety data sheets in various markets. Please be aware that this development has started in early 2019 and is still to be continued for full coverage of relevant markets. The release notes have more info on the scope of each release. Of course, you are still free to create one "Datasheet" per SDS.
The internationalisation of SDScom has a nice side effect for training: All elements that belong to a certain region are clearly marked: They are included in a "RegionXX" tag. So whenever you find a piece of data which has a parent "RegionEU" in its XPath, you know that this element is only relevant for European SDSs. Or at least specific for this region - there might be similar elements for other regions, such as with classifications.
SDScom wants to cover other applications as far as the data can be sensibly written in and retrieved from safety data sheets (see also issue #185):
-
It covers listing information for all known chemical inventories. So, even if you send just one safety data sheet, you can include what your customer needs to know for further exporting the product to other markets.
-
For the EU, it covers parts of the CLP notification according Article 45. It holds most info necessary for notification and represents it in a fashion compatible with the PCN format, but does not include a full or first stage composition (which is a business secret). This data was introduced in version 4.4.0 already. So, if you mix your own products, or trade products under your own name, you have all ingredient information in place. Just add your composition, create a UFI, and notify.
The release manager for this version is Qualisys GmbH, www.qualisys.eu .
Version 4 covers EU safety data sheets and follows the paradigm that one set of data (within the tag "Datasheet") represents one Safety Data Sheet. The development of this version has ended and is superseded with version 5. Version 4.4.0 is a long-term support version and will be maintained until at least end of 2021. This means that it will be adjusted to any regulatory changes that surface during the maintenance period, but there will be no extensions in scope (which in most cases means: no "new fields").
The release manager for this version is eska GmbH, www.eska.eu .