[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Business_specific reference data in representing_part
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]