[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] Issues against assigning_identification and representing_part
Hi Rob,
thanks for the clarification.
The version identification context is only established
by the representation of the part through its classification of the
identification_assignment entity as a type of version_identification_code. I
presume that different subclasses of this would be treated as adding to the
uniqueness rather than all being evaluated as being of the same type e.g.
version_identification_code(s).
For example, I assume could specify a part_version at
version1 using a version_identification_code - plus, I could
also (if required) create another part_version (at version1) using a
progression_identification_code (which is a subclass of
version_identification_code), right?
regards,
Tim From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 07 August 2007 01:56 To: Tim Turner; plcs-dex@lists.oasis-open.org Subject: RE: [plcs-dex] Issues against assigning_identification and representing_part Hi Tim See below
Regards From: Tim Turner [mailto:tjt@lsc.co.uk]
Rob,
Just to ensure I understand correctly what is being proposed, can you disambiguate;
> This rule means that there can be only one version (Part_version) of a part > (Part) with any given identifier.
For example, do you refer to the identifier of the Part or the Part_version in the above? If the latter, then could we narrow this down a little further to something like ... any given version_identifcation_code? [RBN] I mean the identifier of the part_version. It should be unique in the context of the part of which it is a version.
Secondly, how does your example P21 change given the change in the uniqueness constraint? [RBN] It becomes #42083=IDENTIFICATION_ASSIGNMENT('version 1','/IGNORE','$',(#128690)) #42084=IDENTIFICATION_ASSIGNMENT('version 1','/IGNORE','$',(#130652))
where
#42083 and #42084 are PART_VERSION
My last concern is just to ensure that we are still making provision for multiple identifiers that get accumulated over time. [RBN] The constraint has not affect on this.
kind regards, Tim
From: Rob Bodington
[mailto:rob.bodington@eurostep.com] Hi I have just raised these issues against: template assigning_identification template representing_part
They are basically concerned with the unique rule required to ensure that there is only one occurrence of a given part in an exchange file.
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <issue id="RBN-5" type="general" status="open" category="minor_technical" by="Rob Bodington" date="07-08-06"> <description> The template contains the Unique constraint
Unique constraint: Unique identifier There shall be at most one instance of the entity (Identification_assignment) within the data set uniquely identified by a combination of the following template parameters: id, id_class_name, id_ecl_id, org_id, org_id_class_name, org_id_ecl_id. The instance is referenced by the following template parameter: id_assgn.
This constraint is over restrictive. For example, if you have two PARTs A and B, each which have a PART_VERSION at version 1. The constraint means that there will be one instance of IDENTIFICATION_ASSIGNMENT assigned to both PART_VERSIONs E.g. #42083=IDENTIFICATION_ASSIGNMENT('version 1','/IGNORE','$',(#128690,#130652))
Whilst correct according to the model, it means that you cannot assign any dates or effectivity to the IDENTIFICATION_ASSIGNMENT.
It would be better if the IDENTIFICATION_ASSIGNMENT entity was split into the Identifier and the assignment of the identifier. As it stands it does both.
Rather than changing the model, the Unique constraint should be removed and then applied when using the IDENTIFICATION_ASSIGNMENT.
For example, there should be a unique constraint in the Template representing_part that states
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. </description>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <issue id="RBN-4" type="general" status="open" category="minor_technical" by="Rob Bodington" date="07-08-06"> <description> 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.
</description>
Regards -------------------------------------------
Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ.
DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group Ltd. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG, having a place of business at Lincoln House, Wellington Crescent, Fradley Park, Lichfield, Staffordshire WS13 8RZ and at Catherine House, 40a St Thomas Street, Weymouth, Dorset DE4 8EH. VAT number: GB 655 1330 55 DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group Ltd. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG, having a place of business at Lincoln House, Wellington Crescent, Fradley Park, Lichfield, Staffordshire WS13 8RZ and at Catherine House, 40a St Thomas Street, Weymouth, Dorset DE4 8EH. VAT number: GB 655 1330 55 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]