[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] RE: representing part
Why do you need to Id View_definition_context explicitly ? The identifier is provided by the "life cycle stage" and the "application context".
What would be really nice would be to have a standard set of "life cycle stage" and the "application context"
Regards -------------------------------------------
-----Original Message-----
Regarding id on part_view_definition:
I have seen nobody make use of this id. In STEP files I have seen, it has always been left empty, or it has been a made up id for the sake of STEP… I think it should at least be optional.
Talking about identifiers and View_definition_context: I am really missing an identifier for View_definition_context, since these are going to be ‘re-used’ for many imports/exports, and it is very important to be able to identify the View_definition_context and not start creating new View_definition_context by mistake. But this is not covered in any schema as far as I know, and I think this is too late to change in AP239 now….
Peter
From:
Rob Bodington [mailto:rob.bodington@eurostep.com]
Anyone else have views on this?
Regards -------------------------------------------
-----Original Message-----
From:
Tim Turner [mailto:timturner11@bellsouth.net] Hi Rob,
see below.
Regards, Tim
From:
Rob Bodington [mailto:rob.bodington@eurostep.com] Hi Tim I have had a quick look at representing part template.
Could you make the EXPRESS-G diagrams look like all the
other diagrams (i.e. ones drawn by GraphicalExpress, so is it possible to
change the font and the colour of the entities?).
Picky / subjective I know but perhaps we could adopt a
convention for how to draw the product/versio/defitnion entities form top to
bottom? Rather like has been done in product as realized? … just a
suggestion
I am not sure that I agree with passing in the detail as to whether the part is a part or assembly. What is that supposed to tell the receiving system? That the part is an assembly (just about every part is and assembly from someone's point of view) Or is it telling me that there is assembly information in
the file.
It does not imply whether the full assembly info is in the file or not, just that it either exists or does not. [RBN] I still think that this is a really bad idea! I think that we imposing a business practice. One persons detail is another person's assembly.
If I send you a part + its assembly. Then I send you a file that refers to that part. All I need to do is provide sufficient information to identify the part. I do not need to send you the assembly again, nor do I need to tell you that you already received it. In other words the sending system should not have to tell someone whether they have received a part or not, the importer should work that out.
I have spoken to several people who have worked on production systems, including some PDM schema implementations. In nearly all cases they do not send this information. Primarily because in most cases whether something is a detail or an assembly changes depending on who you talk to. Also a detailed part may have product structure and an assembly may have no product structure. (think of a carbon fibre composite. Its starts off as an assembly of plies, which end up as a component ).
In exchanges where detail and assembly were provided, stating whether something was a detail or an assembly was subjective, and the receivers of the information ignored it.
I recommend that we should make this type of information optional. If a business practice needs it then you can add it, but don't force it on everyone else.
The where rule (which is horrible and restrictive) is:
[RBN] So remove the following and make it optional as assigning ref data to the part (not the category) -- provide the type of the part by classification
This should be reflected in the EXPRESS-G
The instance of product_category is further classified with the detail/assembly info to distinguish between those which may have an assembly or breakdown model. By default, the classification is set to detail (i.e has no assembly/decomposition defined for it). [RBN] See above – but I really do not think that we should do this in the template
I am not sure that we need to identify the
part_view_defnition – surely that is identified by the view definition
context? [RBN] The uniqueness of the part view definition is provided by the view_defn_context (Any system will have a set of view_dfn_contexts – these will be unique) and the part version to which the part view defn is attached. Again, the production implementations that we have seen do not need the id and either make it up or ignore it.
I am assuming from the instantiation path that the following parameters part_creator_org_id(Type='STRING') part_creator_org_id_class_name(Type='CLASS')
are to identify the part – they are not necessarily the organization that created the part – more the organization that owns the identifier that is being provided. So perhaps they should not have creator in the name e.g: part_org_id
You are also assuming that the same organization owns the id
for the part and the version …. is that always going to be the case?
Regards -------------------------------------------
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. 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]