[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] RE: representing part
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: 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: 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]