Capability (C003):— representing_assembly_structure Date: 2010/08/26 07:31:30
Revision: 1.30

Issue raised against: representing_assembly_structure

GENERAL issues


Closed issue Issue: TJT-1 by Tim Turner (05-04-11) minor_technical issue
Resolution: Accept. Status: closed

Version 1.10 of this capability contains material developed for the example Dex and introduces tables of contraints, rules and sections which will be moved to the business DEXs area. This capability needs to be reset to the previous version to effect this.
Comment: (Tim Turner 19th Apr 2005)
Capability 1.10 was updated with the content from version 1.9


Closed issue Issue: RBN-1 by Rob Bodington (04-03-22) minor_technical issue
Resolution: Accept. Status: closed

The capability does not describe "attachment slots" at all.
Comment: (Tim Turner Oct 18th 2004)
Attachment slots are briefly discussed and brought in as a dependant capability. They are described fully in the capability representing_slots.


Closed issue Issue: RBN-2 by Rob Bodington (04-03-22) minor_technical issue
Resolution: Accept. Status: closed

The attribute descriptions are in the main body of the text - they should be in the usage section.
Comment: (Tim Turner Oct 18th 2004)
All descriptions have been removed.


Closed issue Issue: RBN-3 by Rob Bodington (04-03-23) minor_technical issue
Resolution: Accept. Status: closed

Should this capability be combined with representing_product_configuration?
Comment: (Tim Turner Oct 18th 2004)
Product configuration was originally part of this capability. However, this concept was determined to be worthy of it's own capability. It was subsequently removed during an effort to update the contents. I presume that the reasoning behind having separate capabilities still stands. My feeling is that if it isn't broken then it does not require fixing.


Closed issue Issue: RBN-4 by Rob Bodington (05-02-23) minor_technical issue
Resolution: Accept. Status: closed

The section describing "Version History Relationships" should not be included in this capability. It should be part of the "representing_parts" capability. The product_version_relationship should be treated in the same way as in representing product as individual, and use the same classification. I propose: Derived_version_relationship Sequential_version_relationship Hierarchical_version_relationship as defined in the PDM Schema usage guide.
Comment: (Peter Bergström 2007-04-13)
Section moved to representing_part.