RE: [plcs-dex] dexlib\data\templates\representing_promissory

Some responses to your comments

Issue: RBN-1 by Rob Bodington (07-04-03) minor_technical issue
Resolution: Accept. Status: open

Why is it mandatory to classify the assembly relationship?

Comment: (Peter Bergström 2007-04-18)
It should not be. Fixed.

Comment: (Tim Turner 2007-08-8)
I disagree. It is useful to distinguish between other types of usages of promissory usage. E.g. I might wish to define it as a BOM view, an APL, etc.. Also, given that the structure is identical to representing_assembly, it would be useful to separate the types of relationship by their use context. This is why there is a relation_type attribute on view_definition_relationship.

Comment: (Rob Bodington 07-08-09)
We are not saying that you cannot assign reference data - just that it should not be mandatory. Hence the classification has been moved to the characterization section. I would have thought that the distinction between the BOM view and an APL view is achieved by different view_definitions - not by classifying the relationships. That is after all what the view definition was designed for.
[Tim Turner] Ok, I understand where you are coming from; indeed the relation_type attribute is also

optional. As for the placing the distinction on each view_definition to define and classify a

parts list (rather than assigning classificiation and identification to the relationship), I

think we need to review the parts list discussion that was had some time ago. I do believe that

most, if not all, documented usages of promissory usage on Dexlib (at the time of creating the

template) were assuming the classification of the relationship in this way, but it is probably

worth revisiting to clarify.

Issue: RBN-2 by Rob Bodington (07-06-25) minor_technical issue
Resolution: Accept. Status: open

representing_promissory usage and representing_assembly should use the same approach to representing the quantity. The quantity should be represented by a representing_quantity template rather than a representing_count. This will allow quantities with units. E.g. 10 litres to be represented as well as counts.

Comment: (Rob Bodington 07-07-06)
This has resulted in changing the quantity parameter to: quantity(Default=1,Type= 'TYPE (any_number_value)' ) unit(Default=Count,Type='CLASS') classifications: "Unit" (urn:plcs:rdl:std:Unit) unit_ecl_id(Default='urn:plcs:rdl:std',Type='URN') si_unit(Default=false,Type='BOOLEAN')

Comment: (Tim Turner 2007-08-8)
Representing_quantity allows bad practice in this context. The original count used to represent quantity restricted the usage with respect to the item in the assembly to the number of occurrences in the assembly or to allow for a quantified BOM. It is not practical to allow a quantity such as 0.5 Kg of Parts within an assembly.

Comment: (Rob Bodington 07-08-09)
So how would represent 10 litres of Oil?
[Tim Turner] I think this is tied up with whether the item refered to is a 'part' or

'non_countable_material', which I think is a carry over from the PDM schema specified in the

product_category assigned to the part. If dealing with a 'non_countable_material', such as sand,

it is not (humanly) possible to use count each grain of sand so a quantified value (with a weight

measure, e.g. Kg) is applicable. For liquid, a volume measure should be used. If classified as a

'part' then count should be used. I think that we should have some constraints to ensure that

these are enforced, rather than permit the misuse of this.

Regards
Rob

From: Tim Turner [mailto:tjt@lsc.co.uk]
Sent: 09 August 2007 14:19
To: plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] dexlib\data\templates\representing_promissory_usage\dvlp\issues.xml

I have just added the following minor technical comments to representing_promissory_usage template.

RBN-1 (Re:removal of classification of the assembly relationship). I disagree. It is useful to distinguish between other types of usages of promissory usage. E.g. I might wish to define it as a BOM view, an APL, etc.. Also, given that the structure is identical to representing_assembly, it would be useful to separate the types of relationship by their use context. This is why there is a relation_type attribute on view_definition_relationship.

RBN-2 (Re:changing from representing_count to representing_quantity). Representing_quantity allows bad practice in this context. The original count used to represent quantity restricted the usage with respect to the item in the assembly to the number of occurrences in the assembly or to allow for a quantified BOM. It is not practical to allow a quantity such as 0.5 Kg of Parts within an assembly.

New minor technical Issue

TJT-1 The characterization shown in Fig5 does not match with those described in the section. Either modify the figure or update the characterizations provided.

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. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG

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

plcs-dex message

Some responses to your comments