OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

plcs-dex message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [plcs-dex] Additional_contexts


Just food for thought but I don't quite follow the logic here.

If there is "possible significant change compared with previous version" then 
the thing is likely a new PVD isn't it? One which would be related to the old 
PVD as a "successor" and only have the one context in which it was valid 
associated with it. You wouldn't delete the previous PVD or its context 
links. 

Back in my IBM days (so I'm not talking in the abstract), new versions of PVDs 
were managed as "iterations" (think of it as as a version of a version). Just 
like for Versions, there were rules about allowed change to PVDs and when the 
change constituted a new Version or Part. If the change is "significant" 
and/or a "structural change" perhaps that's what's really happening?

Sharing definitions across contexts is very common practice and seems like 
something PLCS should support. I know it's not apples and apples but in IBM 
we drove all sorts of downstream apps from the same PVD - i.e. the same CATIA 
geometry model drove NC cutter path definitions, FEA meshes, etc. and we 
didn't duplicate the geometry for each context. It was also possible that the 
next iteration of geometry PVD didn't affect the mesh or cutter path and so 
we kept using them as-was, we certainly didn't delete anything that was 
possibly useful. We also had no problem managing the change as it was clear 
from the PVD iteration number, successor relationship and PVD context 
relationships what was what and who was using it.

DP

On Wednesday 28 March 2007 06:20, Peter Bergström wrote:
> I have been editing the Representing_parts Capability, and have made one
> possibly significant change compared with previous version. It has to do
> with the use of the attribute additional_contexts of entity
> View_definition_context.
>
>
>
> A Part_view_definition must always have a context in which it is valid. The
> problem may start when a p_v_d is valid for several contexts, because then
> it hampers change. If a change is required (e.g. structural change) within
> one context, but not in the others, the additional contexts must be
> removed, and a new p_v_d must be created for that context. The trace of
> changes becomes blurry.
>
>
>
> Therefore, the new edition of representing_parts states the following:
>
>
>
> Even though AP239 allows the definition of additional contexts for a
> Part_view_definition, it is recommended that any Part_view_definition
> <http://www.plcs-resources.org/plcs/stepmod/data/modules/part_view_definiti
>on/sys/4_info_reqs.htm#part_view_definition_arm.part_view_definition>  is
> only related to one, single View_definition_context
> <http://www.plcs-resources.org/plcs/stepmod/data/modules/product_view_defin
>ition/sys/4_info_reqs.htm#product_view_definition_arm.view_definition_contex
>t>  (as the initial context), and that no additional contexts is
> instantiated. Instead of defining an additional context for a
> Part_view_definition, a new Part_view_definition is created (copied) with
> the new context related as the initial context.
>
> NOTE    This recommendation has to do with change management. It is not
> uncommon that part defining information (e.g. structures, properties and
> documents) that was first believed to be identical between contexts (which
> would cause the "additional context" relationship to be instantiated) later
> on is revised, changed or restructured in one context but not in the other.
> To make that change, the additional context has to be removed, and a new
> Part_view_definition must be created for that context. Instead, by
> instantiating two (or more) separate Part_view_definition
> <http://www.plcs-resources.org/plcs/stepmod/data/modules/part_view_definiti
>on/sys/4_info_reqs.htm#part_view_definition_arm.part_view_definition> s,
> with the same part defining information, but each with only one (initial)
> context, such changes are possible from the start and becomes traceable.
>
>
>
>
>
> The other changes made are not changing any technical parts of the
> capability.
>
> Peter Bergström
>
>
> 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.

-- 
Mobile +44 7788 561308
UK +44 2072217307
Skype +1 336 283 0606
http://www.eurostep.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]