Issue raised against: product_specification

Comment: ( )
..(comment text goes here)..

Comment: (Brad Harris 2008-09-10)
Whether NSN is the primary ID or an alias for some other spec is pretty immaterial, Product Specification.Id gives all the functionality required for any sort of aliasing. NSN is just one type of ID, it is not a different attribute to ID.

Comment: (Tim Turner 2008-09-10)
I'm a little confused about the aliasing aspect that you raise, that sounds like another (alternate) identifier. My view is that a specification would always retain its primary organizational provided id, (hence the Product_specification_id) but that it may accrue an NSN_code in addition as the design matures. Hence during life it could be refered to by either, if both were available. Thus in terms of life cycle it does matter which is used because at one point the NSN_code may be empty! However, if the MoD stated that it was a requirement to always have an NSN identifier available for population, then that could easily be added, but at certain times in the lifecycle, this attribute may be an empty string (if the source had no value for it). This would be an additional CBIS attribute. The underlying issue for me is that the specification template is ultimately based upon Part. To include an NSN_code I'll need to extend it to include a resource_item that points at the part. Hence the NSN_code on a resource_item would relate to the Product_specification_code on the Part which is refered to as one of the resource_items via the resource_item_select type.

Comment: (Tim Turner 2008-10-06)
I think I understand where you are coming from on this - because the generic nature if the Identifier template allows one to select any type of Identifier from the 'bucket' of identification types in the rdl. However, when we're assigning an Identifier to a business object it is within that context that the Identifier is cast. E.g. the Identifier for an Organization should restrict the type of Identification to one that is appropriate. Same with Product Specification - hence we have a Product_specification_code that gets assigned to the Part that is playing the role of the Specification. The trouble is that while we could extend the subclasses of this to include an NSN_Code (what I'd normally do), so that the Product_specification.id can be identified as of type NSN_Code, this can only be assigned to a Resource_item (so it states in the NSN_Code description). Hence we'd need to restructure the template completely (or add a Resource_item). This means that we either have to do away with the generic Product_specification_code and use just NSN_Code (and assume that we will never refer to a Product Specification without am NSN), or we assume that an NSN_code is something in addition to a Product_specification_code - or lastly, we assume that Both can/could be present (which I think is closer to the truth). Because they get applied to different things in the Express, means they cannot be merged into a single class and applied to just one Express entity. Hence its a different additional identifier (call it alias if you want) but we either need to make it an explicit additional parameter, or replace the existing one. I think that the former way would be the best way (add additional parameter to the business object) forward at present - we can always review it again later, but I do need to progress this.

Comment: (Brad Harris 2008-10-07)
This is a flaw, Product Specifications exist independently of any part that may conform with them. Two completely different and independent things.If PLCS doesn't recognize this fact of life, then I guess we miuawga. NSNs are one type of product specification. The whole notion that NSN identified parts are "resource items" is again, imho, flawed. NSN's are classifications/specifications and nothing to do with "resources" - for tasks - and to talk about resources independently of tasks, is again - imho - a flawed notion - it just doesn't correspond with what happens on planet earth. Agreed, both (Product_specification_code and use just NSN_Code) can be present. [We need to] correct the notion that NSNs only ever equate to the id of a (task) resource - they don't - they are an independent concept. PLCS has got this wrong and it needs fixing.

Comment: (Tim Turner 2008-10-07)
If we agree that BOTH a product specification code and an NSN Code can be present, then we should also say that both should be present on the business object. Would we also be able to agree that the NSN is optional (and therefore appear in characterization)?

Comment: (Brad Harris 2008-10-07)
If we agree that BOTH a product specification code and an NSN Code can be present, then we should also say that both should be present on the business object. [Brad Harris] Why - not all product specs get an NSN. Would we also be able to agree that the NSN is optional (and therefore appear in characterization)? [Brad Harris] If its an ID, then the alias ID is the place to put it isn't it ?

Comment: (Tim Turner 2008-10-07)
I understand your suggestion about using alias. However, given the current confines of NSN_Code, an alias (really an Identifier pointing to another Identifier) will not suffice because the NSN_code required here can only be applied to the Resource_item entity - not an Identification_assignment. We don't have the time to argue this in OASIS land and get them to change the way they've been using it (although it was previously a subclass of Part_identification_code). At present the only way to affect the idea that not all Product Specifications will receive an NSN, is to either make the CBIS object's ID attribute a many to 1, or add a second optional attribute (NSN). Even in the former is not ideal since it does not allow us to distinguish between the Product_spec code and an NSN_code and which should be assigned to the different entities. This leaves only one current avenue - an optional NSN paramter.

Comment: (Tim Turner 2008-09-10)
Changed to mandatory - should have been all along.