Template:— representing_part (rep_part)
Capability:representing_parts		 Date: 2009/04/28 17:24:29
Revision: 1.36
CoverContentsDescriptionModel diags.Input params.Ref. params.Instantiation pathInstance diags.CharacterizationsIssuesin situ

Issue raised against: representing_part

GENERAL issues

Closed issue Issue: SMB-1 by Sean Barker (2006-03-21) minor_technical issue
Resolution: Accept. Status: closed

The description of the parameters part_id_class_name and part_vn_id_class_name is incorrect, and these should refer to the class, not to the library which holds the class.
Comment: (Tim Turner 2007-04-04)
Corrected

Closed issue Issue: RBN-1 by Rob Bodington (07-04-11) minor_technical issue
Resolution: Accept. Status: closed

There are many businesses where a part or product_as_realized is never versioned, or in at exchange, the version is either, not known, or is not significant, i.e. any version will do as the fit form and function remain the same across versions. However, the templates for representing the part and product_as_realized enforce an identification of a version. I think that we should have a convention for identifying an unkown version and this should be documented in these templates
Comment: (Peter Bergström 2007-04-12)
The capability has a section covering this, under additional usage guide. Let me know if this is not good enough. Do we really have to document this in the template as well? Or do you want a default value of "/NULL" to the version ID? And what do we do about the Part_view_definition and View_definition_context instances that this template instantiates for Parts that have no version - do the Parts ever have properties or sub-assemblies? If so, we need the p_v_d and v_d_c as well. If not, we cannot solve this in one template, and would need a template called "referencing_part_without_version" or similar.
Comment: (Peter Bergström 2007-04-13)
The basic text from the capability has been copied as a note into the description of the template.

Closed issue Issue: RBN-2 by Rob Bodington (07-05-06) minor_technical issue
Resolution: Accept. Status: closed

There should be a unique constraint that ensures that only one product-category is instantiated.
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: (Rob Bodington 07-05-08)
That is what the uniqueness constraint does.
Comment: (Rob Bodington 07-05-08)
Added uniqueness constraint.

Closed issue Issue: RBN-3 by Rob Bodington (07-06-08) minor_technical issue
Resolution: Accept. Status: closed

There should be a unique constraint making sure that only one view_definition_context entity is defined
Comment: (Rob Bodington 07-06-08)
Added constraint

Closed issue Issue: PBN-1 by Peter Bergström (2007-07-05) minor_technical issue
Resolution: Accept. Status: closed

The characterization of a part by part name is not described in the template. This is needed to make the use of correct rdl-class visible.

Closed issue Issue: RBN-4 by Rob Bodington (07-08-06) minor_technical issue
Resolution: Accept. Status: closed

There should be a uniqueness constraint that force a unique part and version. E.g. Unique constraint: Unique part There shall be at most one instance of the entity (Part) within the data set uniquely identified by a combination of the following template parameters: part_id, part_id_class_name, part_id_ecl_id, part_org_id, part_org_id_class_name. The instance is referenced by the following template parameter: part. Unique constraint: Unique part version There shall be at most one instance of the entity (Part_version) within the data set uniquely identified by a combination of the following template parameters: part_id, part_id_class_name, part_id_ecl_id, part_org_id, part_org_id_class_name, part_vn_id, part_vn_id_class_name, part_vn_id_ecl_id, part_vn_org_id, part_vn_org_id_class_name. The instance is referenced by the following template parameter: version. This rule means that there can be only one version (Part_version) of a part (Part) with any given identifier.
Comment: (Tim Turner 2008-02-25)
The two uniqueness constraints mentioned above have already been provided, in addition to the definition context. However, the definition of the part should also be unique in the context given and of a specific version of the part.

Closed issue Issue: RBN-5 by Rob Bodington (07-08-06) minor_technical issue
Resolution: Accept. Status: closed

The Unique constraint: Unique product_category States Product_category.name="Part" and Product_category.name = 'part'. This should only be stated once and should should be 'part'. Unique constraint: Unique product_category There shall be at most one instance of the entity (Product_category) with the attribute (Product_category.name="Part") instantiated in the data set. Product_category.name = 'part'
Comment: (Tim Turner 2008-02-25)
Constraint fixed.

Closed issue Issue: RBN-6 by Rob Bodington (07-08-07) minor_technical issue
Resolution: Accept. Status: closed

The template has the reference parameter: catgy(Type='Product_category') This is not mentioned in the template path. Furthermore, the requirement for this reference parameter is not clear. It is not obvious as to why the Product_category needs to be referenced from outside the template.
Comment: (Peter Bergström 2007-08-15)
I think this ref param was added in the review of the template, because of an ambiguous statement that all entities have to have a reference parameter. I, too, think this ref param should be deleted.
Comment: (Tim Turner 2008-02-25)
The only thing that touches on this is the relationship entity product_category_hierarchy - I think until it has been deemed that this entity will not / shall not be used, we may as well leave this in. It does not add any real overhead, but does allow for other future possible uses that have perhaps yet to be identified or recognized. I have added it to the path.

Closed issue Issue: DNV-59 by Fredrik Lied Larsen, DNV (2007-8-15) editorial issue
Resolution: Accept. Status: closed

Issue file: template_issues_Frell.xls Template: Representing_part Check list clause: 9 "Classified" should be "classified" line 539 in template.xml
Comment: (Tim Turner 2008-02-25)
Issue no longer present in file.

Closed issue Issue: DNV-60 by Fredrik Lied Larsen, DNV (2007-8-15) editorial issue
Resolution: Accept. Status: closed

Issue file: template_issues_Frell.xls Template: Representing_part Check list clause: 15 References to stepmod found.
Comment: (Tim Turner 2008-02-25)
All refs to stepmod or modules removed. Also Refs to class ids are required by dexlib boiler plate in the param inputs section.

Closed issue Issue: DNV-61 by Fredrik Lied Larsen, DNV (2007-8-15) editorial issue
Resolution: Accept. Status: closed

Issue file: template_issues_Frell.xls Template: Representing_part Check list clause: 19 Missing model reviewer and business reviewer
Comment: (Mike Ward 2007-11-23)
Model reviewer and business reviewer now populated.

Closed issue Issue: DNV-62 by Fredrik Lied Larsen, DNV (2007-8-15) editorial issue
Resolution: Accept. Status: closed

Issue file: template_issues_Frell.xls Template: Representing_part Check list clause: 20 Status set to in_model_review
Comment: (Mike Ward 2007-11-23)
Status now set to "reviewed".

Closed issue Issue: DNV-63 by Fredrik Lied Larsen, DNV (2007-8-15) editorial issue
Resolution: Accept. Status: closed

Issue file: template_issues_Frell.xls Template: Representing_part Check list clause: 48 Template reference parameters not shown above abbreviated template rectangle
Comment: (Tim Turner 2008-02-25)
Fixed.

Closed issue Issue: DNV-64 by Fredrik Lied Larsen, DNV (2007-8-15) editorial issue
Resolution: Accept. Status: closed

Issue file: template_issues_Frell.xls Template: Representing_part Check list clause: 51 Description of input parameter "domain" and "life_cycle_stage" is not correct, should be an External_class
Comment: (Tim Turner 2008-02-25)
Fixed

Closed issue Issue: DNV-65 by Fredrik Lied Larsen, DNV (2007-8-15) editorial issue
Resolution: Accept. Status: closed

Issue file: template_issues_Frell.xls Template: Representing_part Check list clause: 73 URN 'urn:plcs:rdl:sample' is not usedin regard to examples.
Comment: (Tim Turner 2008-02-25)
Rejected; the checklist should allow for realistic examples using actual reference data urn/uri.

Closed issue Issue: GYL-1 by Leif Gyllstrom (2007-11-20) minor_technical issue
Resolution: Accept. Status: closed

Product_category.id attribute shall be optional in EXPRESS-G diagrams (both in the Model diagrams and the Characterization sections)
Comment: (Tim Turner 2008-02-25)
Rejected; the .id attribute of Product_category is not used. There needs to be a case made for it's use for agreement.

Closed issue Issue: GYL-2 by Leif Gyllstrom (2008-01-07) minor_technical issue
Resolution: Accept. Status: closed

Description of Input parameter 'part_id_ecl_id' state: 'The location of the External_class_library that stores the classifications used to classify the part.' This should be changed to something like 'The location of the External_class_library that stores the class used to classify the part id.'

NOTE    Its just the ECL for the part id class!

Comment: (Tim Turner 2008-02-25)
Fixed.

Closed issue Issue: GYL-3 by Leif Gyllstrom (2008-01-07) minor_technical issue
Resolution: Accept. Status: closed

Description of Input parameter 'part_vn_id_ecl_id' state: 'The location of the External_class_library that stores the classifications used to classify the part.' This should be changed to something like 'The location of the External_class_library that stores the class used to classify the part version id.'

NOTE    Its just the ECL for the part version id class!

Comment: (Tim Turner 2008-02-25)
Fixed.

Closed issue Issue: GYL-4 by Leif Gyllstrom (2008-01-07) minor_technical issue
Resolution: Accept. Status: closed

Clarify the descriptions of input parameters 'domain_ecl_id' and 'life_cycle_stage_ecl_id'. e.g. ECL stores the Classes not the classifications.
Comment: (Tim Turner 2008-02-25)
Fixed.

Closed issue Issue: GYL-5 by Leif Gyllstrom (2008-01-21) editorial issue
Resolution: Accept. Status: closed

Change reference to the 'part_vn.id' input parameter in the description of input parameter 'part_vn_id_ecl_id' to 'part_vn_id'
Comment: (Tim Turner 2008-02-25)
Fixed.

Closed issue Issue: RBN-7 by Rob Bodington (07-11-21) minor_technical issue
Resolution: Accept. Status: closed

The path has a number of XML comments in it E.g. <-- Product category assignment --> These should be removed. Use -- instead - that is teh commenting mechanism for the path
Comment: (Tim Turner 2008-02-25)
Fixed.

Closed issue Issue: RBN-8 by Rob Bodington (08-01-02) major_technical issue
Resolution: Accept. Status: closed

There should be reference parameters referencing the Identification_assignments so that effectivities and other characterizations can be applied to the Ids
Comment: (Rob Bodington 08-01-03)
In order to be consistent with referencing_part - recommend using part_id_assgn
Comment: (Tim Turner 2008-02-25)
Added ref params for the part id and version id. However, I think there will be circumstances where the view definition id will also be required.

Closed issue Issue: RBN-9 by Rob Bodington (08-01-09) minor_technical issue
Resolution: Accept. Status: closed

There should be a unique constraint ensuring that there is only one Part_view of a Part_version with any given View_definition_context. See representing_product_as_realized template
Comment: (Tim Turner 2008-02-25)
I agree, but without being able to uniquely identify the Part view definition, this will be difficult. Each view definition for a Part version may be identified differently and hence need to have an identification assignment provided. I have addressed the issue consistently with the suggestion to follow the constraint in representing product as realized, but I don't think this is really accurate (it should not refer to the product as this is already handled by an other constraint - however there may be several view definitions defined for a version which is not catered for at present).

Closed issue Issue: BCR1-312 by Fredrik Lied Larsen (08-06-23) minor_technical issue
Resolution: Accept. Status: closed

The template representing_part identifies uniquness constraints for Product_category, Part, Part_version, Part_view_definition and View_definition_context. However there is no uniqueness constraint for the entity Product_category_assignment. This can result in multiple Product_category_assignment for the same instance of Part. There should be a uniqueness constraint on Product_category_assignment that is the same as the one for Product_category e.g. Unique constraint: Unique product_category_assignment There shall be at most one instance of the entity Product_category with the attribute (Product_category.name ="part") instantiated in the data set.
Comment: (Tim Turner 2009-04-28)
It is agreed that in certain scenarios that the absense of a constraint here could present some inconsistencies. However, the constraint cannot be the same as for Product_category because this is a unique constraint against the attribute (name) which is to be constrained to the string 'part'. Product_category_assignment does not have any such local attributes - only attribute relationships. The template language is not rich enough to allow an extended reference to the Product_category entity from Product_category_assignment, so a separate uniqueness rule has been added to ensure that the Product_category_assignment that references the Part is unique.