Issue raised against: representing_product_as_realized

The template representing_product_as_realized is closer to a business object that shall represent the product than to a template which is reusable in many DEXes. We need a higher level of granularity for a template that references a product_as_realized.

Proposal: Review construct of template representing_product_as_realized and split it into smaller templates. In particular it is suggested to remove the reference to Part from the template. It is conceivable that a Product_as_individual will be related to other entities than Part, for instance Breakdown_element.

Comment: (Peter Bergström 2007-05-21)
A Product_as_realized (and Product_as_individual) is identified in the context of the type model, e.g. its original design. The serial number cannot be considered unique outside that scope. Therefore, it is essential to give the Type identification for any Product_as_realized, as well as the id (serial number).
The problem arise in how this template does that, namely by instantiating the design entities through template representing_part. The idea with this was that if that part already exist, a relation should be created. If it does not exist, it has to be created (which requires a uniqueness constraint to be written to that effect here). However, as it is documented in the input parameter "type", it is anticipated that a Breakdown_element could be the type from which the Product_as_realized was manufactured, or rather, that the Breakdown_element carries the Type identification. The instantiation path do not allow us to create branches in the instantiation, so it is not possible to have either Part or Breakdown_element instantiated here, therefore the most common is chosen. This is not a good design, but the alternative, to have two different templates depending on if the Type ID is carried on a Part or a Breakdown_element is insane - who would know that? The design might even be differently mapped in two distinct systems. If we would have a "Referencing_product" template, this might have been possible to use here with good results, but I'm not sure.
As a solution, the representing_part template instantiation could be taken out of this template, and the Product_design_to_individual would just have an input parameter "Type" to reference the Part or Breakdown_element entity instance. Then this template would still have to reference the design (Part or Breakdown_element), which I see as an important aspect of the Type identification of an individual product, but it would lack the precision in that it would not indicate owner of the design, or classification of Type id.
Would this be a reasonable solution to this issue?

Comment: (Rob Bodington 07-11-21)
See RBN-1 - the representing_part has been removed

Comment: (Peter Bergström 2007-05-17)
This was described in the Capability. A note is added in the description section. If no version exists, the version ID is set to "/NULL".

Comment: (Rob Bodington 07-08-07)
This template uses representing_part and defaults the part verison to unknown. It is not clear why we need to mention the part_version at all in this template. The relationship is between the product_as_individual and the part. The relationship between the Part_version and the product_as_realised is not in scope. Having an unknown version when we do not need to refer to the version is confusing. We should either create a referencing_part template and use that or instantiate a part and relate to that.

Comment: (Peter Bergström 2007-08-15)
This template do not use the Part_version, only indirectly through the use of template representing_part, which includes a version. All values of the Part_version is set automatically in the path, therefore the "unknown" version. I see three alternative solutions to this, if you are not satisfied with the current solution:

1. develop a referencing_part template and use that.
   this is probably the nicest way, since the referencing_ and representing_ will not be 100% overlapping. I still see no major differences in doing this and what is already here...
2. replace the use of template representing_part with a simple instantiation of a single entity Part.
   My arguments against this is that we don't get the Product_category instantiated, and if there is a template for representing a Part, why shouldn't we use it?
3. Omit the representation of Part all together in this template (as suggested as a solution for issue DNV-28a)
   I'm not fond of this solution either, since I believe the "type ID" (the Part) is part of the identifier of a Product_as_individual.

Comment: (Rob Bodington 07-11-17)
The proposal is to:

1. remove the template representing_part
2. Leave the entity product_design_to_individual
3. show product_design_to_individual assigning to the part instantiated by the template referencing_part, but grey out the template referencing_part.
4. Create a new parameter "design" with type Product, that links to referencing_part - that way allowing links to breakdowns if required
5. delete the template parameters required for representing_part
6. The template should make it clear that if the part is NOT known, then referencing_part should be used with the parameters set to /NULL i.e. unknown.

Comment: (Rob Bodington 07-11-20)
Following PLCS core team telecon 20-12-2007, it was agreed:

1. remove the template representing_part
2. remove the entity product_design_to_individual and replace with Product_design_version_to_individual
3. show Product_design_version_to_individual assigning to the part_version instantiated by the template referencing_part, but grey out the template referencing_part.
4. Create a new parameter "design_version" with type Product_version, that links to referencing_part - that way allowing links to breakdowns if required
5. delete the template parameters required for representing_part
6. The template should make it clear that if the part is NOT known, then referencing_part should be used with the parameters set to /NULL i.e. unknown.
7. Make sure that the Express-G reflects the model

Comment: (Rob Bodington 07-11-21)
Implemented proposed change

Comment: (Leif Gyllstrom 2007-05-06)
MAke sure that there's only one instance of Product_category in a data set (i.e. common to all Parts, Breakdowns etc)

Comment: (Peter Bergström 2007-05-17)
This template does not itself instantiate any Product_category, it is made through the Representing_part template. Therefore, the unique rule should go in the Representing_part template instead.

Comment: (Rob Bodington 07-11-21)
All figures now have master attribute

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
All editable files now included

Comment: (Rob Bodington 07-11-21)
class id is used for parameters

Comment: (Rob Bodington 07-11-21)
This is an XSLT issue

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
Addressed

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
It is - this is an issue against the checklist

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
Improved

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
It is - this is an issue against the checklist

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
this is an issue against the checklist

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
view_def_context are instantiated by this template

Comment: (Rob Bodington 07-11-21)
Added some constraints

Comment: (Rob Bodington 07-11-21)
Added

Comment: (Rob Bodington 07-11-21)
Now sequential

Comment: (Rob Bodington 07-11-21)
Corrected

Comment: (Rob Bodington 07-11-21)
Description improved

Comment: (Rob Bodington 07-11-21)
Changed

Comment: (Rob Bodington 08-01-02)
Added ref parameters

Comment: (Rob Bodington 08-01-02)
Added ref parameter

Comment: (Rob Bodington 08-03-01)
removed