Business_specific reference data in representing_part

[Peter Bergström <peter.bergstrom@eurostep.com>]

Tim,

 

I would like you to change the reference data template used for view_definition_context life_cycle_stage and application_domain in template representing_part from assigning_reference_data to assigning_business_specific_reference_data.

 

This issue comes from implementing post-processors, where it is not always possible to know what reference data should be mapped to what attribute of view_definition_context without having access to the correct RDL. This happens as soon as other values is used than those defined in the OASIS standard reference data library. An example: If I chose to define ‘production’ as a life cycle stage and ‘electronics’ as an application domain, it is impossible for computers to understand what value belongs to which attribute (or field), without access to the RDL.

 

I do not intend that it should be OK to import files without performing a validation of the import file, and consolidation with internal data. I do think, however, that we should not mandate how the exact implementation of the import is done (i.e. in what order the different steps are performed, e.g. validating P28 against xml-schema, cashing data into internal memory, consolidating against existing data, load data, or whatever the steps are). A post-processor must be able to perform validation and consolidation of data, but it does not have to know the definition of reference data, or what the content of the file really means. It just need enough data to perform its job.

 

I’m not saying that a PLCS file should be understandable without access to the RDL at all times, but I’m saying that for a post-processor to be able to load and compare an exchange file with the internal database, the access to the RDL must not required. If we demand that, post-processors will be slowed down significantly, and imports will be vulnerable to internet down-periods and such. But with a simple use of assigning_business_specific_reference_data for all cases where there are two assignments of reference data to one entity, where they are supposed to be mapped against two discrete attributes or fields in the database, this problem will be easily overcome. This does not apply to cases when you have multiple classifications, since all those values should be mapped to the same field or concept. The only occurrence I know of is for the view_definition_context where we have life_cycle_stage and application_domain, and they are impossible to separate or combine without the RDL, as the template is written now. This may also be the case where we have both identifier and name attributes for data where it is not possible to separate a name from an identification using string comparisons, for instance. However, there are not many entities which have both a required name and a required identifier, and even less templates that requires both. I know that the view_definition_context is a problem for post-processors.

 

And if we do not build in a solution to this problem already in the DEXlib templates, we will never be able to build post_processors that can operate optimized without immediate access to RDLs.

 

So please, could you change the use of asg_ref_data in template representing_part into asg_business_specific_ref_data (with fixed values for the plcs_class)? This change does not change the parameters defined, only the path (and the diagrams), so it is really a quite harmless change.

 

See template representing_product_as_realized as an example.

Peter

This message contains information that may be privileged or confidential and is the property of Eurostep Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.