All Issues

DEX Issues

Issue raised against: aviation_maintenance

The mapping of Maintenance activity is not done in accordance with the intended usage of the PLCS entiities Activity and Activity_actual. The Activity entity shall deal with the information related to the planned work, whereas the Activity_actual shall deal with the information recored throughout the performance of an activity. The mapping in Figure 5 does not show this distinction. The mapping of the maintenence activity should include both Activity, Activity_actual and Activity_happening entities. There should probably be two "assigning_activity" templates used, one for the relationship between the Activity (i.e. the planned) and one for the Activity_actual (i.e. the recorded).

The assignments of "assigning_time" representing the planned start , and planned end shall be assigned to the Activity entity. So should also the "assigning_process_property" representing expected man hours, and the "assigning_identification" that identifies the Maintenance activity.

Comment: (Rob Bodington 07-03-28)

I think that you were reviewing an out of date copy. The maintenance activity is represented by the template representing_work_done. This contains an Activity_actual related to an activity by Activity_happening. The related activity is the Directed_activity which is part of representing_work_order.

The assignments of properties, people etc, are all assigned to the Actual_activity in the template representing_work_done

The mapping of the link to a predefined maintenance task (choosen_method) in figure 5 should relate to a Task_method_version, instead of a Activity_method. This would allow for versions of Maintenance Tasks. (see DEX 3, TAsk set).

Comment: (Rob Bodington 07-03-28)
There was an agreement that the a work order and typical activity would be described by an activity_method which is them related to a task - if appropriate, by an Activity_method_realization. That way the DEX does not enforce the use of Task - which some business processes do not support

The mapping of NSN in figure 5 is not in line with other mappings done (e.g.) TLSS. There has been a discussion on representing NATO Stock Items as Resource_items, and not assign the NSN directly to the Part.

Comment: (Rob Bodington 07-03-28)
We are not referring to a NATO Stock Item. We are saying that this part (or product as realized) has been classified by this NSN number. It is a classification. We are not referring to a resource item. My understanding was that was the TLSS approach as well.

We should not use the Resource_as_realized_resource_item.quantity attribute, but use a property assignment instead. (figure 14)

Comment: (Rob Bodington 07-04-18)
Why?

Why is the NSN assigned to a Product_as_realized. A product as realized is always related to a Part, which in turn..... Also see issue GYL-5

Comment: (Rob Bodington 07-03-28)
See GYL-5

How do we represent the relationship between LCN number (breakdown) and part number.

PLCS representation sections should be amended to reflect the style of Representing state of a reportable item

Comment: (Trisha Rollo 2007-04-16)
Done: Representing a message Representing a maintenance work order Representing reportable item maintenance activity Representing a reportable item Representing properties on a reportable item Representing replaced parts Representing installation/removal position on an aircraft Representing a reportable item usage activity Representing reportable item location Representing related components Representing change of Part Number, Serial Number, and NSN Representing Inventory Gain and Loss Awaiting: Representing Task extensions

2 Related DEXs ......Product operational information. The procedures ........ This full stop seems wrong. Possibly a colon?

Comment: ( )

3 Scope ......items life ........ I think we also need health. eg "pressure" in a tyre; max pressure during sortie for an engine stage.

Comment: ( )

4 Business Process ......Removal and evacuation -> Repair/Overhaul ........ These seem to be reasons for removing an item, but not activities in themselves. I do not see how they differ from "Removal".

Comment: ( )

5 Inventory activities .......Gains To Inventory -> Loss to inventory ........ Are these part of the AM DEX, or are they covered by DEX 8? If the purpose is to say "this asset is now mine", and "this asset is no longer mine" then it probably is part of this DEX. My intent for this when discussing LITS data was for Inventory Gain to provide all the information about the asset. That is probably the purpose of DEX 8 for status, and this DEX for history of maintenance.

Comment: ( )

6 Information Model Product usage information .... Possibly include "operating environment"?

Comment: ( )

6 Information Model Product usage .... I think that health is required here. eg "maximum operating temperature" Health is a measure that must be within a given range; may be one of "between A and B"; "less than A" "more than A".

Comment: ( )

6 Information Model Product usage Serviceability change This activity reports when a serviceable, uninstalled item .... Also applies to aircraft.

Comment: ( )

6 Information Model Product usage Serviceability change .....rejection .... I'm not sure about the term "rejection". Examples I might use are "maintenance has become due" and "an operator has identified a fault".

Comment: ( )

6 Information Model Removal of Serviceable Reportable Items for Controlled Exchange ............ Should this state that the installation is reported as a separate, related, Installation activity?

Comment: ( )

6 Information Model Lifing extension ...........date........ It is not "date"; it is the life value

Comment: ( )

6 Information Model Lifing extension ...........tasks........ It is not "tasks" in general; it is "maintenance activity is due"; The maintenance activity may be "discard the part" for finite life.

Comment: ( )

6 Information Model Maintenance ..........approved........ Is it just "approval" or is it other task life-cycle activities, such as recording effort; recording task completion; recording task coordination? In general, I thing it is recording management information about the maintenance activity whereas the other items are recording what happened to the asset.

Comment: ( )

6 Information Model Loss to inventory ..........has be decommissioned ........ typo: "been"

Comment: ( )

6 Information Model Maintenance work order .......... I had previously said that Sapphire allows multiple "asisings" ("observations"/"symptoms") on a work order.. I am advised that this is incorrect. Sapphire has a concept off "work package", which is a group of Work Orders to be addressed together (eg grouped by trade) and allocated to one person to "manage". The allocation of work orders to a work package is a manual process in Sapphire; A work order must be part of a Work Package for Sapphire to allow work to be recorded. I have not seen anything in the DEX that would allow "Work packages" to be passed.

Comment: ( )

7 Aviation Maintenance - Implementation details .......... It is a little confusing in this section that the template names do not reflect the names in the diagram. eg: "Template: #1 representing_product_as_realized " rather than "Template: #1 Reportable Item".

Comment: ( )

9 Business information .....required, see: Section: . ..... Missing reference.

Comment: ( )

Template #1 (Figure 5): .....Local_time........... This says "local time", but subsequent commet ("offset") suggests that time should be UTC, not local.

Comment: ( )

ap239_id_class_name: .....the message (Message) of the message............ No make sense to me

Comment: ( )

Figure 6 — UML model representing a maintenance work order Maintenance_activity ............ Should there be something related to this identifying who did it; resources used, etc, or does that come later?

Comment: ( )

Figure 6 — UML model representing a maintenance work order Repair_overhaul ............ Does this also cover the case where an asset is removed and returned to stores? I belive it is "any removal where there is no immediate plan to fit either to the same position or to another position or end-item.". As such I think the name is misleading.

Comment: ( )

10 PLCS representation ............ feel that these sections would be better organised with the diagram before the description. It took me a while to realise that the template numbers were referring to the later diagram rather than to an earlier diagram.

Comment: ( )

10 PLCS representation .......Reportable_item.NSN NATO Stock Number of the reportable item ..... This may be a "domestic" code

Comment: ( )

10 PLCS representation .......Reportable_item.supplier_code ...... NOTE The supply code ..... "NOTE The supplier code"

Comment: ( )

11 Representing a reportable item 12 PLCS representation ..... This seems to say that the "description" is against a part spec (PLCS "part"). Also need description against the specific part, as Sapphire allows specific comments.

Comment: ( )

11 Representing a reportable item 12 PLCS representation ....., it is advisable to use the template representing_product_as_realized.......... Surely the DEX should say one or the other, or if they are equivalent (which they don't appear to be to me), then show the digram with the template included.

Comment: ( )

13 Representing properties on a reportable item Reportable_item_property.value_type ....., sortie.......... Does this mean that "sortie" would be used for a health measurement, such as "presure"

Comment: ( )

14 PLCS representation.......... This does not seem to allow for calendar-based items. Calendar-based items should give dates for "last occurred" or "next occurs", and should not (in my opinion) give"how long since" or "how long until" values. The "how long" approach requires calculation on the receiving side to provide "current" data. eg receipt of '10 days to go' needs calculation to show the true "time to go" if, for example, the data were received 3 days ago.

Comment: ( )

14 PLCS representation.......... It seems to me that there are three distinct cases that need to be defined: a) Life values, where numerics and deltas are required, b) "sortie" (health/consumption) values, where numeric and "current" is required; no deltas. c) Calendar-based values, where absolute date/times are required (possibly with deltas?). Since there are different required/optional sets here, it seems to me that these should be modeled separately.

Comment: ( )

14 PLCS representation.......... "Increment" is shown as required. I believe it has no meaning when a "sortie" metric is being reported.

Comment: ( )

14 PLCS representation..........it is advisable to use the template............... Similar comment to above

Comment: ( )

16 Business information........., see: Section: . ............... Missing reference.

Comment: ( )

16 Business information........., spare ............... Does this mean "serialised"?.

Comment: ( )

17 PLCS representation........... The UML shows serial number as an attribute, but I see no representation of this in PLCS.

Comment: ( )

17 PLCS representation.........out of scope ............... Even if in scope, what is actually used may differ from the spec in the task. eg some parts may be "on condition" rather than "always".

Comment: ( )

17 PLCS representation..........it is advisable to use the template............... as above

Comment: ( )

19 Business information......... The section heading is Representing installation/removal position on an aircraft, but the section is about history and does not reference a position in any way. There may be several positions in a parent to which a part can be fitted, eg a blade on a rotor head. The whole section is about "what" and "when" and "what to", but not "where". "Where" is needed too (PAC/SAC in LITS).

Comment: ( )

20 PLCS representation......... This seems to bear little relationship to teh UML

Comment: ( )

20 PLCS representation.........The position of the reportable item on the aircraft is represented in the Aviation maintenance DEX by referring to the next higher assembly and the aircraft (or end item) from which the reportable item is removed/installed. ................ As above, I believe this to be inadequate.

Comment: ( )

20 PLCS representation.........The serial number which identifies the specific reportable item, and the NSN ................ Also need part no and CAGE code.

Comment: ( )

20 PLCS representation.........The serial number which identifies the specific reportable item, and the NSEach date when the installation / removal occurs is represented ................ I believe a statement is needed on what this means when part A is fitted to part B and then part B is fitted to a/c C and part A is subsequently removed.

Comment: ( )

21 Representing a reportable item usage activity........... Usage_................. The names used here do not match the UML diagram

Comment: ( )

21 Representing a reportable item usage activity........... template #2................. This is shown as optional; I would have thought mandatory, unless it is intended to obtain the date/time from the "sortie" by reference to something in the "sortie" record for the end item. If this latter is the case, then it should be explained.

Comment: ( )

21 Representing a reportable item usage activity........... Usage_profile.start_time ................ This does not appear to be represented in the PLCS.

Comment: ( )

22 PLCS representation................ I'm not sure what is intended to be represented here. Is it the sortie, or is it the usage from the sortie, or both? I would have expected the sortie and the usage from the sortie to be shown separately.

Comment: ( )

Figure 20 —................ What does the bit about a business DEX mean?

Comment: ( )

Figure 20 — UML................ Symptoms do not necessarily come from usage. They can come from inspection or "accident" such as "it fell off the lorry". Can this be represented?

Comment: ( )

Figure 20 — ........not operating correctly................. Not quite. It means that the item is considered to have a defect; investigation may or may not find this to be true.# For example, with electronic kut it is common practice to replace several items without determining which are faulty, on the basis that getting the aircraft serviceable is important; determining which iteactually caused the fault can be done in slower time.

Comment: ( )

Figure 20 — ........UML Class definitions................. I don't see anything in here that covers "Asset Condition", which is a sub-classification of "Unserviceable" for assets, such as test, repair, scrap

Comment: ( )

Figure 20 — ........Fault -> requirements ................ I think this should be "specification".

Comment: ( )

Figure 20 — ........Fault_status.deferred_to..........This could be a date, ................ There is a specific "deferred to date" attribute, so how is this expected to be used? I would guess that it would be better to keep it as a numeric life metric plus metric value. Although reading further, it looks like this is just the value, with the metric being identified in deferred_to_metric

Comment: ( )

Figure 20 — ........Symptom.........performance ................ I'm not sure "performance" is quite right, but it is difficult to think of another term. Possibly "usability".

Comment: ( )

Figure 20 — ........Symptom.flight_safetey_hazard ................. affect ................ "effect"

Comment: ( )

Figure 20 — ........Symptom.whenhow_source .................. who ................ Can also be "discovered" by monitoring systems such as HUMS (Heath and Usage Monitoring System)

Comment: ( )

Figure 20 — ........Servicability_status.organization ............. Serviceability Change ................ Clarity: There are two changes: Into state; Out of State. I believe it is "at the start date".

Comment: ( )

Figure 22 — ................ This suggests that template #3 is mandatory. I believe it to be optional.

Comment: ( )

Figure 22 — ................ Template #8 is referenced from text, but I don't see it in the diagram.

Comment: ( )

24 PLCS representation.............. Symptoms ................ Should there be some description of #13 and #16?

Comment: ( )

24 PLCS representation.............. Symptoms ........known........ I think a different word or phrase is needed here. A fault is "kown" once it occurs. It is possibly "common" faults or "faults forseen by the manufacturer"

Comment: ( )

24 PLCS representation.............. Symptoms .......#18....... I think this should be #12.

Comment: ( )

24 PLCS representation.............. Faults and States .......#7....... Believe should be #22

Comment: ( )

24 PLCS representation.............. This should not be confused with the code that is used to identify and the state type - these are represented by reference data and are set as parameters in the template. ....... I don't understand this bit.

Comment: ( )

24 PLCS representation.............. first by an assessed state, then once the fault has been confirmed though measurement for example, by an asserted state. ....... Is this required, or can there be just an asserted state?

Comment: ( )

24 PLCS representation.............. In addition many applications . ....... Missing word(s)?

Comment: ( )

24 PLCS representation.............. , in which case the state is identified by the template #8 and #4 assigning_identification. . ....... Are you saying that in general the state may be represented in one of two ways a) By reference to state definition; b) by explicit value?

Comment: ( )

24 PLCS representation.............. The dates when the fault was identified and rectified ....... I'm unclear what the meaning of these are, in particular start and end of "assessed" and any relationship to start of "asserted".

Comment: ( )

Figure 24 .............. What is the "geographical feedback report"?.

Comment: ( )

26 Business information.............Location_history.status_at_exchange.............. I'm not entirely sure why this is needed. I guess it is what LITS records, for some reason, rather than determining it when required. I do recall that EPMS used to give conflicting data when different histories were compared, because it stored "A when B chganged" and "B whenm A changed" history, but treated each separately so that when both changed at the same time it would give something strange. Is there the possibility that by tagging "value of A when B changed" could give different results to a query on the underlying data of the form "what was the value of A when B changed?"?

Comment: ( )

27 PLCS representation.............#1 representing_work_done and described in detail in Section: .............. I believe that location change is not part of maintenance work. It is the result of a decision made outside the maintenance arena.

Comment: ( )

27 PLCS representation.............asserted state .............. Items removed from aircraft and returned for repair probably have an assessed state but not an asserted state (maintainer believes them to be faulty, but this is not confirmed until assessed in the maintenance bay).

Comment: ( )

29 Business information.............. I don't understand what this message is forhow it will be used.

Comment: ( )

Figure 27 — .............. This seems to say that NSN is required to identify a product_as_realized. NSN is optional.

Comment: ( )

32 Business information........... It is not only during repair/overhaul. It may be that the exact part fitted is not known, so is allocated a "temporary" identifier. When the part is eventually accessed or removed for some reason, the true identitity may be revealed. The true identifier may then be set by a change of part/serial number. Sapphire provides a function to allocate part numbers and serial numbers to parts that are known to be fitted but exact details are not known. This may also result in a change of CAGE code. but it looks like this may be catered for as the "Part" defines CAGE code. BUT does CAGE code need to be identified explicitly in th ediagram?

Comment: ( )

33 PLCS representation The UID ........ I don't understand what "UID" represents in the real world.

Comment: ( )

36 Business information ........ Tasks may also be given negative extesions, for example to reflect stress or damage caused in unusual circumstances.

Comment: ( )

36 Business information ........particular fault occurs,.................... These cannot be extended because extensions are against metrics. These tasks may be deferred.

Comment: ( )

36 Business information ........delayed.................... Tasks may also be given negative extesions, for example to reflect stress or damage caused in unusual circumstances

Comment: ( )

36 Business information ........Task_execution_trigger .................... Task Execution is conditional. For example, a task may be applicable only in certain operating conditions, or when part is fitted in a particular position. Therefore probably need to have an "active" attribute to specify whether or not the task will be triggered when the limit is reached (whether or not the task is applicable in the current environment). I believe this is needed so that queries don't suggest that a task has not been triggered when it is not applicable.

Comment: ( )

36 Business information ........Task_extension ...... Task_extension.extended_percentage_of_interval .....The percentage .................... I believe that this should be cumulative. The cumulative percentage is needed because that is what determines the overall effect of the extension. Possibly two attributes needed: delta and cumulative. Looking further, it looks like "required" items are deltas for this instance and "extended" are cumulatives. A bit more explanation might be useful.

Comment: ( )

36 Business information ........Task_extension.max_permissible_extension .......... The maximum permissible extension allowed for a Standard Maintenance Task minus the total percentage extension assigned. .................... I'm not sure about this one. The name seems wrong (it should be something like "permissible_extension_remaining")

Comment: ( )

37 PLCS representation .............. I think that this one is beyond me in my current state of knowledge and tiredness, but a couple of observations follow!

Comment: ( )

37 PLCS representation ..............The Condition, Condition_assignment and Condition_parameter are all instantiated by the template #4 assigning_condition ................... This seems to be saying that the conditions for the task execution trigger are being sent. Is that coorect, and if so, then the question is "should we send the conditions?". Or is this representing the fact that a condition has changed? It seems to me thatthe only condition is "metric reaches threshold" and we are just passing information about a change to the threshold and not about the condition itself.

Comment: ( )

37 PLCS representation ..............#5 representing_numeric_property ................... How are date/time limits represented?

Comment: ( )

Comment: (Rob Bodington 07-03-28)
The DEX now uses the latest templates

The text under "Reportable_activity.reporting_organization" and "Reportable_activity.reporting_person" should probably refer to the reporting organization/person instead of as now, the one who undertook the activity.

Comment: (Rob Bodington 07-03-30)
Corrected

The mapping of Reportable_item.previous_part_numbers and Reportable_item.previous_serial_numbers in figure 10 should use Dated_effectivity instead of "assigning_time" representing start/end dates.

Comment: (Rob Bodington 07-04-18)
Corrected

Reportable_item_property is probably not a good name, since its usage is limited to recorded values. Suggestion rename to e.g "Reportable_item_recorded_property" (or measured or...)

Comment: (Rob Bodington 07-03-30)
It is used as a value for a task trigger as well. The intent is to provide a scoping model rather than a detailed model

Figure 18 (EXPRESS_G diagram for representing a usage activity) shoud be reworked in accordance with the issue GYL-1.

Comment: (Rob Bodington 07-03-30)
The diagram has been redrawn to use the template reporting_product_usage

Figure 26 (EXPRESS_G diagram for new PN, SN and NSN) should use Dated_effectivity instead of "assigning_time" representing start/end dates (Also see issue GYL-4).

Comment: (Rob Bodington 07-04-18)
Corrected

Figure 15 - note needs adding to figure about the use of template (similar to that in figure 11).

Comment: (Trisha Rollo 2007-04-11)
Figure 15 has been amended to add note

Maintenance_work_order.maintenance_organization is the “Maintenance Organization raising the Maintenance Work Order” . This also contradicts the PLCS representation statement which indicates the organization conducting the maintenance.

Comment: (Trisha Rollo 2007-04-11)
work order requires both organizations, amended

Fig 9 should show an approval. There should also be a template table and text

Comment: (Trisha Rollo 2007-04-11)
Figure 9, template and text amended

How is an unknown or not required version number identified

Comment: (Rob Bodington 07-04-18)
This is described in the capability representing part

Representing a reportable item/PLCS representation /Part – referencing capability rather than template: (For details of identification, see the capability: C001: assigning_identifiers and the template: C001: assigning_identifiers). Should state (For details of identification, see the capability: C001: assigning_identifiers and the template: assigning_identification).

Comment: (Trisha Rollo 2007-04-12)
text amended

Representing a reportable item / Figure 11 should show both Manufacturing and owning organizations of the part. PLCS representation needs to reflect this also

Comment: (Trisha Rollo 2007-04-11)
Figure 11, template table and text amended

Figure 13 is wrong – it is missing view_defn_context . PLCS representation needs to reflect that this would be part of the template representing_product_as_realized.

Comment: (Trisha Rollo 2007-04-11)
Figure 13 and PLCS representation amended

Representing properties on a reportable item/PLCS representation words explaining property_value_relationship or time, organization and value type required

Comment: (Trisha Rollo 2007-04-11)
PLCS representation amended

Figures 7,11,13,15,17,19,25,27 and 29.need references to other figures completing

Comment: (Rob Bodington 07-04-18)
Corrected

Representing replaced parts – need to clarify what is the difference between this and intstalling parts - trackable versus non trackable STItems.

Comment: (Trisha Rollo 2007-04-13)
PLCS representation amended

Maintenance work order PLCS. The PLCS seems to contradict the figure. In the figure the assigning_activity relates the r_p_a_r for the end item to the r_w_o, and not the r_p_a_r for the reportable item.

Comment: (Rob Bodington 07-04-18)
Corrected.

The template representing message had changed producing errors

Comment: (Trisha Rollo 07-06-15)
amended to reflect updated template.

Issue raised against: fault_states

Comment: (Rob Bodington 05-11-30)
Added

Issue raised against: maintenance_plan

Issue raised against: operational_feedback

Comment: (Rob Bodington 05-02-18)
Corrected

Issue raised against: product_breakdown_for_support

Issue raised against: product_as_individual

Comment: (Tim Turner 04-09-02)
Re-worded

Issue raised against: task_set

Issue raised against: work_package_definition

The section "Documenting the Definition of activities" states:

The definition of an Activity has been harmonized with the mechanism defined for defining tasks (see DEX 3), to enable a consistent, interoperable approach. This effectively treats the definition as a Document attached to the Activity identified.

I could not find this in DEX 3, and further more I would have thought that the definition of an activity should be done by assigning a document to an activity_method.

The DEX states:

The Approval_assignment links the Work_order to an Approval. The Approval_assignment shall in these circumstances be classified as a "Work_order_approval" (urn:plcs:rdl:std:Work_order_approval) (a sub-class of "Approval_assignment_role" (urn:plcs:rdl:std:Approval_assignment_role)).

I am not sure that there is a requirement to use reference data to make a distinction between what is being approved. It is sufficient to just the Approval_assignment with no classification as specified in the templates.

Capability Issues

Issue raised against: assigning_approvals

Comment: (mikeward 2004-08-16)
Agreed. Capability revised.

Comment: (mikeward 2004-08-20)
Agreed. Capability revised.

Comment: (Rob Bodington 04-08-19)
The approval status should continue to be used. Reference data should be used to provide the possible statuses.

Comment: (mikeward 2004-08-20)
Note added to State capability.

Comment: (Mike Ward 2005-01-07)
Agreed. Capability revised.

Comment: (Rob Bodington 06-06-20)
It is not obvious what the different functions of reference data for approval assignment and approval are. Hence, only approval is classified. The text has been expanded.

Comment: (Peter Bergstrom 2006-04-15)
Templates added.

Comment: (Rob Bodington 06-01-23)
I have just removed the offending /IGNORES from the path The same problem occurs in Approving_person_organization.approval_date = '/IGNORE' The diagrams still need to be updated.

Comment: (Peter Bergstrom 2006-04-15)
Diagrams corrected.

Comment: (Rob Bodington 06-02-01)
I would prefer Option 1. The EXPRESS-G and the path should be updated accordingly.

Comment: (Peter Bergstrom 2006-04-15)
I chose a different solution, because of the following: An approval may authorized by a person (in an organization) or by an organization (no person identified or mentioned), at least thats my understanding of the business overview. I therefore created a third template, assigning_approving_organization (and renamed the other one to assigning_approving_person), and the three templates are now not within each other (since there is a choise of a person or organization, they cannot be). This poses another syntactical problem in that it is now possible to assign only an assigning_approval, without either a person or an organization, and I cannot enforce that in the path syntax. See further issue PBM-1. However, it is no longer a problem of not accessing the reference_parameters...

Comment: (Peter Bergstrom 2006-04-15)
Three templates have been added: assigning_approval, assigning_approving_person, and assigning_approving_organization.

Comment: (Peter Bergstrom 2006-04-15)
corrected.

Comment: (Peter Bergstrom 2006-04-15)
The identification of a person is now optional.

Comment: (Peter Bergstrom 2006-04-15)
Corrected.

Comment: (Peter Bergstrom 2006-04-15)
Corrected, I think...

Comment: (Rob Bodington 06-06-20)
The prose text is acceptable

The capability has attempted to use the assignment of dates to approvals and Approving_person_organization by using the assigning_calendar_date template rather than the date attributes Approval.planned_date Approval.actual_date and Approving_person_organization.approval_date. The rational being that date assignment should be used everywhere in dexlib to enable the assignment of multiple dates. For example, there may be a requirements to assigned more than one date to the Approving_person_organization.

However, the AP239 model does not permit the assignment of a date time to Approving_person_organization. The options are therefore:

1. Use the date attributes and the representing_date_time template
2. Use the date assignment for the Approval and the attribute Approving_person_organization.approval_date
3. Raise a SEDS against PLCS and use the date assignment everywhere

The proposal is to use option 1 as this in keeping with the original model and raise a SEDS to allow the assignment of a date to Approving_person_organization.

Comment: (Rob Bodington 06-06-20)
Option 3 has been implemented. A SEDS has been raised, and the a modified schema added to dexlib. See dexlib/docs/issues/infrastructure_issues.xml#RBN-58

Comment: (Rob Bodington 06-06-23)
corrected

Person_in_organization and organization is represented in templates related to other capabilities. The template assigning_approval doesn't include the entity approving_person_organization which is required.

New template: assigning_approval_person_organization (asg_apr_pers_org) which contains approval, approval_assignment, approval_status, approving_person_organization (with references to proposed new templates repr_person and repr_org.)

Comment: (Peter Bergström 2007-05-22)
This is formally an issue against the templates, not the capability. Therefore I have closed it.
However, I have also commented similar issues in the template, and instead of using the new template I suggest we change the existing one. However, the change is dependent on how templates are reorganized for Organization and Person, so I wait with the changes until I know the resolution of those issues.

Assigning_approvals has 3 templates. Currently the the template assigning_approval has to either refer to the template assigning_approving_person or assigning_approving_organization. The templates assigning_approving_person and assigning_approving_organization have both the entity approving_person_organization and then refer to either person or organization. As suggested in issues related to capabilities representing_person_in_organization and assinging_organization the part representing person_in_organization and organization should be part of such capabilities and not part of assigning_approval. If these parts are replaced by references to other templates the two templates only include the entity approving_person_organization.

This leads to the proposal to make the two templates assigning_approving_person and assigning_approving_organization obsolete and either include the entity into assigning_approval or create a new template beside assigning_approval (see DNV-09).

Comment: (Peter Bergström 2007-05-22)
This is formally an issue against the templates, not the capability. Therefore I have closed it.
However, I have also commented similar issues in the template, and instead of using the new template I suggest we change the existing one. However, the change is dependent on how templates are reorganized for Organization and Person, so I wait with the changes until I know the resolution of those issues.

Issue raised against: assigning_codes

No explicit resources exist in AP239 to support exchange of codes in a robust manner. The proposed idea of populating Class.name with the code value may not be fully satisfactory. Some inputs to this discussion are forwarded by document 20050818_Codes and descriptors.doc (distributed by e-mail), and an alternative approach is indicated.

Suggest 2 para reworded.

Was:

Codes are often used to simplify the classification or characterization of a specific type of object. Each code is a shorthand for a specific term defined within a classification system. This type of codes are often used in legacy applications where the number of characters used were absolutly crucial. The amount of codes used by existing applications are to extencive to be expected to be defined in reference data libraries, prior to the realization of data exchanges including these codes.

Codes are often used to simplify the classification or characterization of a specific type of object. Each code is shorthand for a specific term defined within a classification system. This type of codes are often used in legacy applications where the code has a fixed character length and the different fields in the code have meaning.

Each individual code value used by existing applications could be defined in a reference data library prior to any data exchange. However, the number of codes in use is likely to make this prohibitive. Consequently the coded value will be exchanged and reference data used to define the type of the code.

Comment: (Leif Gyllstrom 05-10-10)
Change done according the proposal above.

I think that there is room for confusion between codes used as a classification and codes used for identification. A part number may well be a code. When it is used to identify a part, identification assignment should be used. I think that this needs to be stated in this capability. I also think that an example showing the classification of the part number should also be provided.

Suggest including something along the lines of:

Codes are strings that are structured according to some convention. Often different sets of characters within the string carry a particular meaning. For example, part numbers are sometimes made up of a set of strings, with each set carrying some meaning. For example, product function, manufacturing plant etc. Structured codes are traditionally used for two purposes:

Identification - the code provides an identifier for something. For example a part number or serial number.

Classification - the content and structure of a code provides information about the classification of whatever the code is assigned to. For example, the first 4 characters in a part number may indicate the function of the part. NATO Stock Numbers are examples where this is the case.

Where the code is being used for identification, the capability C001: assigning_identifiers should be used.

This capability, assigning_codes, should only be used

Comment: (Leif Gyllstrom 05-10-10)
Clarification provided within the additional usage section.

Comment: (Leif Gyllstrom 05-10-10)
Changed the template name to assigning_code.

Comment: (Leif Gyllstrom 05-10-04)
Done.

Issue raised against: assigning_date_time

Comment: (Peter Bergström 2007-04-12)
This no longer appears to be the case. Issue must have been corrected without documenting it.

Comment: (Peter Bergström 2007-04-12)
Figure numbering in templates corrected.

Comment: (Peter Bergström 2007-04-12)
Already fixed, but not documented.

Comment: (Rob Bodington 06-06-23)
Parameters can be bound in the instantiation path without them necessarily being declared as the reference parameter - local variables in affect. Having said that, it makes sense to make to bind Date_or_date_time_assignment to a reference parameter so that additional classifications can be made. The same issue is against assigning_time. Both have been updated.

Comment: (Rob Bodington 06-06-28)
Modified

Issue raised against: assigning_descriptor

Comment: (Tim Turner 20 april 2006 17:51)
From: Tim Turner [mailto:tjt@lsc.co.uk] Sent: den 20 april 2006 17:51 To: 'plcs-dex@lists.oasis-open.org' Subject: [plcs-dex] Assigning_descriptor I would like to be able to specialize the descriptor classification for use with assigning_descriptor. However, the template fixes the class_name assigned to the document to be 'descriptor', rather than making this the type associated with an optional input parameter. With an optional parameter of type class 'descriptor', we would be able to characterize the descriptor into appropriate sub-classifications (mentioned in the capability), such as notes, remarks, comments etc.,. Any application will still know that any of the above are of type 'descriptor' through the class hierarchy. Would there be any objection to making this minor modification to the template definition, before I submit an unworthy issue? Kind regards, Tim

Comment: (Peter Bergström [mailto:peter.bergstrom@eurostep.com] 20 April 2006 17:46)
-----Original Message----- From: Peter Bergström [mailto:peter.bergstrom@eurostep.com] Sent: 20 April 2006 17:46 To: 'Tim Turner'; plcs-dex@lists.oasis-open.org Subject: RE: [plcs-dex] Assigning_descriptor I think this is fine, especially if you supply a default value ‘descriptor’ for the new parameter. Then nothing will change for existing usages… Peter --------------------------------------------------------------------------------

Comment: (Rob Bodington [mailto:rob.bodington@eurostep.com] 20 April 2006 12:59)
From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 20 April 2006 12:59 To: peter.bergstrom@eurostep.com; 'Tim Turner'; plcs-dex@lists.oasis-open.org Subject: RE: [plcs-dex] Assigning_descriptor I agree with Peter – it should be fine so long as you add the default. Regards Rob

Comment: (Leif Gyllstrom 2007-05-02)
Defining the type of descriptor being assigned is done by classification of Document_assignment. There is no need for specializing the classification of Document as well. Therefore is the issue rejected.

Comment: (Leif Gyllstrom 05-10-06)
Note added to the introduction.

Comment: (Leif Gyllstrom 05-10-04)
Added

Comment: (Leif Gyllstrom 05-10-04)
Text added.

Comment: (Leif Gyllstrom 05-10-04)
Changed.

Comment: (Leif Gyllstrom 05-10-06)
Section added.

Comment: (Leif Gyllstrom 05-10-04)
Done

Comment: (Leif Gyllstrom 05-10-06)
Done.

Comment: (Leif Gyllstrom 05-11-06)
Product_category isn't required. This is a missunderstanding. Se Issue RBN-1 below.

Comment: (Leif Gyllstrom 05-11-06)
Added.

Comment: (Leif Gyllstrom 05-11-06)
OK

Comment: (Leif Gyllstrom 05-11-06)
Added.

Comment: (Leif Gyllstrom 05-11-06)
An issue against all capabilities, and not explicitly assigning_descriptor.

Comment: (Leif Gyllstrom 05-11-06)
Corrected.

Issue raised against: assigning_document_properties

Issue raised against: assigning_effectivity

There is a need to assign product_as_individual_effectivity to product and support data, e.g. to relate a breakdown_element to it's parent product.

Proposal: Add NEW template Assigning_product_as_individual_effectivity (asg_p_a_ind_eff) containing Effectivity_assignment (classified) and a Product_as_individual_effectivity (optional classification) relating to a Product_as_individual.

Comment: (Tim Turner 19th Apr 2005)
Capability 1.8 was updated with the content from version 1.7

Comment: (Tim Turner 28th Jun 2004)
Accepted. Done.

Comment: (Rob Bodington 06-06-28)
Modified

Issue raised against: assigning_identifiers

Comment: (Peter Bergström 2007-05-24)
No, it should be listed in the underlying template/capability instead.

There is a need to represent a code with its description and explicit reference to its encoding system (C093 does not contain description and does not reference the encoding system explicitly).

Proposal: Add NEW template to C001 called representing_code (repr_code) with the associated name and reference to the encoding system used.

Identification_assignment.identifier (with reference data as per example 1 hereafter) holds the code_name, and is referenced by either an encoding system document or an instance of assigning_descriptor (C095). The Identification_assignment is classified by an internal class (with reference data as per example 1) where Class.name holds the "name". An organization shall optionally be assigned Identification_assignment the same way as in template assigning_identification.

• For an instance of Representing_code, the Identification_assignment providing the "code" (e.g. Identification_assignment.identifier="3") shall be assigned Reference data that specifically identifies the type of code (e.g. "Safety_code"). The Class entity that holds the "name" associated with the "code" (e.g. Class.name="Critical") is assigned Reference data that specifically identifies the type of name (e.g. "Safety_code_name"), applying the postfix "_name" to reference data name assigned to the code.
• Rule 1: For an instance of Identification_assignment there shall be one instance of Assigning_referenced_document classified as Encoding_system or one instance of Assigning_descriptor addressing the code origin.
• Mapping rule 1: If neither Encoding document nor description exists in the population, populate Assigning_descriptor. Document.description with "/NULL".

Comment: (Peter Bergström 2007-05-24)
Codes should be handled as described in Capability assigning_codes. That means that using your example above, you use template assigning_code and give the code (e.g. "3") in parameter class_code and assign a reference data class (e.g. "Safety_code" in param code_class_name) representing the encoding system, to give it a meaning. What's missing here is of course the description of what the code means ("Critical"), but the reference data class (code_class_name) defintion should point you to the definition of all codes. You just have to use a code_class_name that is specific to your classification codes, "Safety_code" is not enough.
You could also define each code as a reference data class, and use assigning_reference_data. That would give you the exact definition for each code immediately, and that definition would probably say what encoding system you use as well.
I think it is wrong to provide the definition of the code in instance data, as suggested above. As soon as you enter the world of reference data, you should not provide further information about that data in the instance file, but through the class definition and description.
I see no need for a new template here.

Comment: (Tim Turner 05th Feb 2004)
Characterization revised. Overview updated. Examples and model diagrams updated.

Comment: (Tim Turner 05th Feb 2004)
Empty issue

Comment: (Tim Turner 19th Apr 2005)
Capability 1.32 was updated with the content from version 1.28

Comment: (Tim Turner 18th Oct 2004)
Fixed

Comment: (Tim Turner 18th Oct 2004)
Not an issue against the capability. Closed.

Comment: (Tim Turner 18th Oct 2004)
Fixed

Comment: (Tim Turner 18th Oct 2004)
Not sure that i understand the question/issue. I think that each PAR is a separate version (that exists), therefore, it would have a different serial number to any other version. Assigning identifiers does not deal with versions. Actually, I shouldn't have used serial number as another type of identification for a Part - since this is at the design stage - NSN would have been better example. Raise another issue to clarify the question if required.

Comment: (Tim Turner 12th Nov 2005)
Example updated and problem fixed.

Comment: (Tim Turner 12th Nov 2005)
Added clarification on difference between identifiers and codes to the business overview section. There are several examples of part type codes (aka part number) being assigned and classified as such.

Comment: (Tim Turner 12th Nov 2005)
I assume that this is to enable users to specify the reference data library, rather than have it hard coded. Will work on it.

Comment: (Tim Turner 13th Nov 2005)
I believe that by including assigning_identification_with_no_organization (as suggested by RBN-8 - that refers to the same template), that this issue is closed.

Comment: (Tim Turner 12th Nov 2005)
Working on it.

Comment: (Tim Turner 13th Nov 2005)
Now added to C001

Comment: (Tim Turner 12th Nov 2005)
Description emboying above added.

Comment: (Tim Turner 12th Nov 2005)
Fixed.

Comment: (Tim Turner 12th Nov 2005)
Removed.

Comment: (Tim Turner 12th Nov 2005)
Re-formatted.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 12th Nov 2005)
Fixed.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 12th Nov 2005)
Removed.

Comment: (Tim Turner 12th Nov 2005)
Fixed.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 12th Nov 2005)
Re-formatted.

Comment: (Tim Turner 12th Nov 2005)
Done.

Comment: (Tim Turner 29th Nov 2005)
Fixed.

Comment: (Tim Turner 29th Nov 2005)
Fixed.

Issue raised against: assigning_location

Comment: (Rob Bodington 06-11-11)
Moved to the template assigning_location

Issue raised against: assigning_organization

There is no template for relating an organization to another organization. Currently the entity Organization_relationship is only present in C016 Representing_person_organization.

Proposal: NEW Template called "asg_org_rel" (assigning_organization_relationship): The template describes the relationship between two organizations classified using assigning_reference_data.

The OASIS cap C094 assigning_organization doesn't include the entity Organization_relationship therefore we suggest to add this to C094 and add a new template for the relationship."

Comment: (Peter Bergström 2007-05-24)
The only reason to create a template for the relationship is to make the classification of the relationship clearly visible, but it might not be necessary? We would get very many templates if we did this for every relationship... It should however be clearly described in the Capability.

This issue is related to the proposal of the new template assigning_organization_relationship and this template to be part of assigning_organization capability (C094) instead of representing_person_organization (C016).

Should the name of the capability be changed to representing_organization with one template called assigning_organization and the new template called representing_person_organization

This issue is related to the proposal of a new template assigning_organization_relationship to be part of assigning_organization.

The capability assigning_organization (C094) doesn't include the entity Organization_relationship (currently only available as part of representing_person_organization). The entity needs to be added to the capability in order to be able to add the new template.

Comment: (Peter Bergström 2007-05-24)
I agree, regardless if we have a new template or not the Capability must deal with the relationship.

Templates such as assigning_approving_organization need to reference an organization (similiar assigning_approving_person need to reference person_in_organization). Organization should be represented independently and referenced.

Proposal: NEW Template called "repr_org" (representing_organization): The template describes an organization when its only role is its existence without an entity approving_person_organization. This makes it easier to relate organizations to an organization hierarchy or e.g. approving_person_organization.

The template consists of the entity organization with the assigned templates as described in assigning_approving_organization as well as an optional assigning_address .

Comment: (Peter Bergström 2007-05-24)
This is a good idea, since there are entities whose attributes refer to Organization, see for example template assigning_approval.

Comment: (Rob Bodington 06-06-21)
The capability now specifies the use of assigning_location.

Comment: (Rob Bodington 05-11-18)
assigning_classified_identification renamed to assigning_identification_with_no_organization and moved to assigning_identifiers capability

Comment: (Rob Bodington 06-06-26)
Updated

Comment: (Rob Bodington 05-10-26)
Updated

Comment: (Rob Bodington 06-06-21)
Yes - this capability requires the use of the template assigning_identification_with_no_organization which is defined in the capability assigning_identifiers

Issue raised against: assigning_product_properties

Comment: (Ian Bailey 2003-03-29)
Words have been altered in line with Rob's comment

Comment: (Ian Bailey 2003-03-29)
Reference has been changed

Comment: (Ian Bailey 04-03-29)
I was assuming that AP239 would not use independent_property as you are mandating reference data. It doesn't make much sense to define a standard property twice.

Comment: (Tom Hendrix 04-05-07)
In the pdm schema there is a notion of a "definitional" independent property. Perhaps something like a material specification. Is classification suitable for this sort of assignment?

Comment: (Ian Bailey 2004-05-10)
I think classification (reference data) is perfect for this. I spoke to Rob and he thought we weren't using independent property. One for the PLCS modellers to resolve, I think !

Comment: (Tim Turner 2004-06-17)
I certainly agree that we shouldn't have alternative ways to represent the same thing and there appears to be little push from Dex1 team to have this. I picked it up from the initial Dex 1 spec - not knowing that there was any agreement to abandone it for the Dexs. Another one of those "nuggets" no one knows about!

Comment: (Ian Bailey 2003-03-29)
The attribute you need is actually called "rep" and is imported as far as I can see in the usage section. Does this fix your problem ?

Comment: (Tim Turner 2004-06-17)
Yes fixed: - reps are now in the model!

Comment: (Ian Bailey 2003-03-29)
Does it need to be specified in this capability ? Surely the dependent and related capabilities sections in the other capabilities define which entities the properties can be assigned to ?

Comment: (Tom Hendrix 04-05-07)
Since the scope is only products, why not show a Product_view_definition in the select. All others in the scope of this capability are subtypes of this.

Comment: (Ian Bailey 2004-05-10)
I've done as Tom suggested, but left this issue open - do we need to consider properties being assigned to view_definition_relationship instances also ?

Comment: (Tim Turner 2004-06-17)
The property_assignment_select type population is now resolved. I think it was a problem in the longform generator back in March. Not sure about properties being assigned to view_definition_relationship instances. Can only see a need if there's a requirement to place properties on relationships between products e.g. alternate_part_relationship may have some sort of property governing it's use - but I rather think that might be treading on the effectivity ground. I'll let you decide if you want to close this Ian.

Comment: (Ian Bailey 2004-07-28)
Sounds like we have agreement, issue is now closed.

Comment: (Rob Bodington 04-07-29)
The select gets populated by the long form generator - not by capabilities.

Comment: (Ian Bailey 2003-03-29)
Examples for parts and requirements now added.

Comment: (Ian Bailey 2003-03-29)
Re-arranged text appropriately. Used definition from PDM Schema usage guide.

NOTE    In addition to products, properties can be assigned to activities, described in C077: assigning_process_properties and resources, described in C078: assigning_resource_properties.

Comment: (Ian Bailey 2003-03-29)
Added note - also did this for process properties.

Comment: (Ian Bailey 2003-03-29)
I disagree. This does not map onto any commercial systems I know. Nor does the PDM Schema usage guide mandate this.

Comment: (Rob Bodington 04-09-28)
Agreed.

Comment: (Ian Bailey 2004-05-10)
Changed in line with Tom's comments

Comment: (Ian Bailey 2004-05-10)
Surely the products capability should do this ?

Comment: (Rob Bodington 04-09-28)
Added line in introduction.

Comment: (Ian Bailey 2004-05-10)
Because of the need to configuration manage requirements, requirement is a subtypes of product. If you wish to assign a required property to an activity, you must first assign a requirement and then represent that requirement with your property.

Comment: (Ian Bailey 2004-05-10)
Done

Comment: (Ian Bailey 2004-05-10)
Well spotted !

Comment: (Rob Bodington 04-07-29)
Agreed. This capability should mention the fact that properties can be assigned to documents as part of the introduction . However, the representation of document properties should be part of the document capability - or a separate capability. See Issue RBN-1 against representing_document.

Comment: (Rob Bodington 04-09-28)
The introduction has been updated. The capability "assigning_document_properties" has been implemented.

Comment: (Rob Bodington 04-09-28)
Diagrams updated.

Comment: (Mike Ward 2004-12-23)
Diagrams amended accordingly.

Comment: (Mike Ward 2004-01-25)
Diagrams amended to reflect current status of reference data.

Comment: (Mike Ward 2004-01-25)
Diagrams amended to reflect current status of reference data.

Comment: (Mike Ward 2004-01-25)
New section added.

Comment: (Peter Bergström 2006-04-16)
External classification is used through template assigning_reference_data, because we want the property name to be defined as reference data.

Comment: (Peter Bergström 2006-04-16)
fixed.

Comment: (Peter Bergström 2006-04-16)
Capability has been edited, and figures changed...

Comment: (Peter Bergström 2006-04-16)
I think this issue is outdated, and do not understand what is meant. This capability does not have any Activity_property_representations.

Comment: (Peter Bergstr minor_techicalouml;m 2006-04-16)
The assignment of a property has no longer a date/time assignment, not even an optional one. Since the assignment of a property _may_ be done without giving any value, and since properties may have several representations which may be recoded at different times, it makes no sense. Instead The representation of the property can have a date/time assigned, which is recorded in capabilities C079: representing_properties_numerically, C080: representing_properties_textually, and C084: representing_property_value_ranges. This moves the date/time much closer to the actual value.

Comment: (Peter Bergström 2006-04-16)
This has already been fixed, but the issue was not closed.

Comment: (Peter Bergström 2006-04-16)
Fixed.

Comment: (Peter Bergström 2006-04-16)
Fixed.

Comment: (Peter Bergström 2006-04-16)
Fixed.

Comment: (Peter Bergström 2006-06-08)
Fixed.

Comment: (Peter Bergström 2006-04-16)
Fixed.

Comment: (Peter Bergström 2006-04-16)
Fixed. Although there are a lot of other things a property may be assigned to, so I selected a few as examples.

Comment: (Peter Bergström 2006-04-16)
Fixed.

Comment: (Peter Bergström 2006-04-16)
Annotated figure to show value, unit and property name.

Comment: (Peter Bergström 2006-06-27)
Hopefully this is now fixed, most graphics are new.

Comment: (Peter Bergström 2006-06-08)
Neither am I, and I agree that this should preferrably be handled by the structure and classification of reference data. Until there is a place to move this section (if needed) I will keep the section inside a comment in this capability, so it can be inserted somewhere else, but it will not be a visible part of this capability.

Issue raised against: assigning_process_properties

Comment: ( )

Comment: (Peter Bergström 2006-05-18)
Fixed.

Comment: (Peter Bergström 2006-05-18)
Fixed.

Comment: (Peter Bergström 2006-05-18)
I think this is true for many of the abundant subtypes of this part of the model... Will look into it.

Comment: (Peter Bergström 2006-06-05)
The discussion regarding use of subtypes of Value_with_unit and Unit have now been moved to capability 096 Representing_value_with_unit. This issue have been addressed in that section. My standpoint in doing this was the following: The semantics of values should be given in the attribute name referring to them, or in the property class name which they represent. A value is a value. Therefore, the use of Duration and Uncertainty_with_unit have been deprecated, except when the schema explicitly refers to these.

Comment: (Peter Bergström 2006-05-18)
Yes, C077 is applicable to both, hence its name: Assigning_process_properties. I do not know however if there is a real difference in usage with activity and task_method (I though not), can you provide some examples?

Comment: (Peter Bergström 2006-06-05)
The overview now mentions all 'super-entities' that can have process properties. It is assumed that the reader understands that process properties can be assigned also to their subtypes.
I do not think there is a difference between a duration property if it is assigned to a task_method rather than to an activity. A planned_activity is basically the same as its corresponding task_method, except that it is planned (scheduled, although not necessarily with a defined date/time) for a specific individual (or type). At least the (invented) property 'estimated duration' would be the same. There is however a difference that a task_method should not have an Actual_duration, since the task_method itself is a type - it is instantiated as an activity. But this is a difference between task_method and activity, not regarding their property assignments, and it should be discussed in other capabilities dealing with task_method and/or activities. Note that a planned_activity or a directed_activity should also not have properties classified as 'actual_xxx'. The only activity that should have 'actual_' properties is the activity_actual.

Comment: (Peter Bergström 2006-05-03)
I have renamed the template assigning_process_properties, and changed wording in the capability to explain to what entity instances a process property can be assigned.

Comment: (IanBailey 04-05-10)
Fixed in line with Tom's comments

Comment: (IanBailey 04-05-10)
Fixed in line with Tom's comments

Comment: (Tom Hendrix 04-05-06)
fixed

Comment: (IanBailey 04-05-10)
Fixed in line with Tom's comments. In terms of having a standard notation, that's a question for Rob !

Comment: (IanBailey 04-05-10)
Fixed in line with Tom's comments

Comment: (IanBailey 04-05-10)
Fixed in line with Tom's comments

Comment: (Peter Bergstrom 2006-05-03)
Template has been added, and now renamed to assigning_process_property.

Comment: (Peter Bergström 2006-06-05)
Is this needed more than a description of how to assign a condition, an approval, an identification, a document, a language_indication, a justification or a task_method (just to mention a few) to an activity_property? Or shouldn't this be described in a capability for how to assign effectivities?
I think we might have a philosophical issue here: If something is not described in the capability, but the schema allows it, is it then not allowed (or deprecated) in the OASIS guidelines? Is it 'illegal'? Especially now with the templates, I can sense an unspoken conception that nothing except what's in the templates (or capabilities) is allowed. I would like this to be true, since life would be easier then, but I fear that we have forgotten to mention a lot of 'common sense' assignments to many entities in all of the capabilities in that case (just look at the list at the beginning of this paragraph!). Maybe we need to decide what 'conformance' to the OASIS PLCS DEXs or Capabilities really mean? And then possibly add all those assignments to all capabilities?
Or maybe I have just misunderstood this issue altogether...?

Comment: (Peter Bergström 2006-06-21)
The PLCS schema allows effectivity to be assigned to a property, not a value. Please provide some examples that show the business requirements for assigning an effectivity to a property.

Comment: (Peter Bergström 2007-05-17)
No further info received. Closed.

Issue raised against: assigning_resource_properties

Comment: ( )

Comment: (Peter Bergström 2006-05-18)
Done.

Comment: (Peter Bergström 2006-05-18)
Done.

Comment: (Mike Ward 2004-01-31)
Classification of Resource_property revised.

Comment: (Rob Bodington 04-09-29)
Added as PLCS ballot comment: 10303-1282 IBY-6

Comment: (Ian Bailey 2004-05-10)
Fixed for all modules in this series.

Comment: (Ian Bailey 2004-05-10)
Fixed.

Comment: (Ian Bailey 2004-05-10)
Fixed.

Comment: (Ian Bailey 2004-05-10)
Good question. Normally, we would use a requirement instance and assign it. However, required_resource is sort of a requirement in itself. However, by shortcuttting the requirement assignment process we'd end up with requirements being handled in two different ways. Any views ?

Comment: (Mike Ward 2004-01-31)
Classification of Resource_property revised.

Comment: (Ian Bailey 2004-05-10)
Oops! There quite a few of those typos. Now fixed.

Comment: (Ian Bailey 2004-05-10)
I'm not sure if the ISO rules apply, but I've changed it anyway.

Comment: (Ian Bailey 2004-05-10)
Done

Comment: (Peter Bergström 2006-05-18)
Done.

Issue raised against: assigning_reference_data

Comment: (Peter Bergström 2007-05-04)
If a leaf class can also be one of the Express entities, I would say yes (however, that might have to be made clear in the text here). All reference data must always a subclass of something in the AP239 schema.

In order to process OWL correctly, the reference data library that is the most specialized rdl must be identified as the context ontology. The context ontology must include all other rdl's in an exchange file. This should be achieved by classifying the most specialized External_data_library as the "Context_ontology".

This template should describe how to achieve this, both in text and using an instance example. An OWL class "Context_ontology" has to be created. Possibly, a specific template has to be developed for this.

Comment: (Leif Gyllstrom 07-04-23)
This issue has been moved from the template 'assigning_reference_data', since the context ontology should only be refered to once within a message. However, the usage of context ontology should also be mentioned within the assigning_reference_data capability.

Comment: (Peter Bergström 2007-05-04)
Any External_class_library entity representing a specific, identified RDL should only be instantiated once in a data set (although there is currently no uniqueness constraint in the template to that effect, which I think is incorrect, see issue PBM-3 for template assigning_reference_data). That fact makes this capability just the correct place to do it. What would be a better place?

Comment: (Leif Gyllstrom 05-06-13)
Version 1.9 is reset to the content of version 1.6

Comment: (Leif Gyllstrom 05-06-13)
Done

Comment: (Leif Gyllstrom 05-06-23)
Done

Comment: (Leif Gyllstrom 05-06-23)
Done

Comment: (Leif Gyllstrom 05-10-06)
Removed the usage of Attribute classification as the means of controlling standard values. Added a section under Additional usage guidance.

Comment: (Leif Gyllstrom 05-10-06)
Done

Comment: (Leif Gyllstrom 05-10-06)
Added information about 15926 and PartsLib.

Comment: (Leif Gyllstrom 05-06-23)
Added in both textual description and in the template.

Comment: (Leif Gyllstrom 05-06-23)
All figures replaced

Comment: (Leif Gyllstrom 05-06-23)
Added section under Additional usage guidance. However, recommendation is to use PLCS standard class 'Unknown'

Comment: (Leif Gyllstrom 05-06-23)
Added section under Additional usage guidance

Figure 5 in assigning_reference_data template shows Class.description="/IGNORE" and External_class_library.description="$" They should be consistent.

The following attribute values are permitted:

• Empty string '' indicates user data managed by the sending system but not provided for data exchange.
• String '/NULL' indicates user data in a mandatory attribute that is not managed by the sending system or currently not known.
• $ is used in the physical file, if an optional attribute is not instantiated.
• Attribute values are set to '/IGNORE' when the information that could be held be the attribute is instead assigned to the instance of the entity.

Based on this, the following attributes should be set: External_class_library.description="$" Class.description="$"

Comment: (Leif Gyllstrom 05-09-21)
Rejected. Guidelines for populating non-used attributes has changed in accordance with the approach used in the figure.

Comment: (Leif Gyllstrom 05-10-03)
This is provided by the template assigning_business_specific_reference_data.

Comment: (Leif Gyllstrom 05-10-04)
Added

Comment: (Rob Bodington 06-01-17)
Corrected

Comment: (Leif Gyllstrom 2007-05-03)
The figures being adressed belongs to a template that has been deprecated.

Comment: (Rob Bodington 06-01-19)
Corrected

Comment: (Leif Gyllstrom 2007-05-03)
The mentioned inconcistensy only appears in the template that has been deprecated.

Comment: (Leif Gyllstrom 2007-05-03)
The mentioned inconcistensy only appears in the template that has been deprecated.

Issue raised against: messaging

Comment: (Rob Bodington 07-01-31)
This has been raised as SEDS #1135 roblem Description: The use of message always requires the use of the escape mechanism to reference items, whereas, in some cases an AP may wish to restrict the usage to particular entities. Suggest: The entity Content_item should be subtyped (oneof) to Content_item_selected and Content_item_reference Content_item would become an abstract type, and the current attributes migrated to Onservation_item_reference Content_item_selected would have a single attribute pointing to an extensible select. Additional Notes: An AP could chose to define the set of things an observation is restricted to by a rule allowing only the Content_item_select subtype and extending the associated select.

Comment: (Rob Bodington 07-01-31)
The model diagram in the template has been modified to show Content_item_selected. The EXPRESS needs to be modified and the SEDS addressed.

Comment: (Sean Barker 2004-03-08)
Revised Messaging now satisfies the requirement.

Comment: (Sean Barker 2004-6-10)
Additional section added on semantics of Acknowledge.

Comment: (Sean Barker 2004-4-26)
Should be raised as issue against Envelope module, where categories should be an enumeration.

Comment: (Sean Barker 2004-4-26)
Issue raised against Envelope Module

Comment: (Sean Barker 2004-4-26)
Corrected

Comment: (Sean Barker 2004-4-26)
Corrected

Comment: (Sean Barker 2006-2-24)
Done

Issue raised against: report_activity_progress

Issue raised against: representing_activity

The template assigning_activity only contains the entity applied_activity_assignment (classified) without other options (see characterization).

There is a general issue about separate templates for assignments, the usage of optional associations in the template versus creating bigger templates with explicit definitions of the content as well small templates referencing each other which needs to be considered.

Proposal: New template assigning_actual_activity (asg_act_act) containing the entities applied_activity_assignment (classified), activity_actual (identified), activity_method (identified, classified).

Representing_activity has a mandatory reference to assigning_time. This is very restrictive and most likely not needed normally, if the source data doesn't contain data on start time then it will be impossible to populate. It should therefore be possible to exchange activity data without identifying date_time.

Proposal: Make time optional in all templates in Representing_activity (assigning_activity, representing_typical_activity, representing_planned_activity, representing_product_usage, representing_activity_actual, assigning_work_output, ...).

Comment: (Peter Bergström 2007-05-24)
Do you have the date in your source data, or in the source system? If so, I think you just set the hour to "12" or "0" or what you like, and it works fine with assigning_time. But if you don't even have the date, I think we have a problem. To me, its a minimum requirement when reporting activities to say what date it was. I'm very hesitant at making asg_time optional, because I think it almost makes the template unnecessary... What do other projects think? Should all dates and time be optional for all activities (even planned and actual)?

The template assigning_activity only contains the entity applied_activity_assignment (classified) without other options (see characterization).

There is a general issue about separate templates for assignments, the usage of optional associations in the template versus creating bigger templates with explicit definitions of the content as well small templates referencing each other which needs to be considered.

Proposal: New Template assigning_activity_method (asg_act_meth) or extension of the existing assigning_activity (asg_act) containing the applied_activity_assignment (classified), activity (classified), activity_method (identified, classified).

Note: differs from the DVN-10 in use of entity activity_actual vs. activity.

Comment: (Rob Bodington 06-06-21)
This has been clarified in the text.

Comment: (Rob Bodington 06-06-21)
The activity_method_realization is not brought into the capability as that would bring in Task etc which are deliberately out of the scope of this capability. The intent is to provide the minimum required to represent activity. The text has been reworded.

Comment: (Rob Bodington 06-06-21)
The text has been reworded

Comment: (Rob Bodington 06-06-23)
The typical activity is used to provide a specification of the activity that could take place. If the activity can be described, then it is typical.

Comment: (Rob Bodington 04-03-27)
activity_method_realization is part of scheme and task capability. So excluded from the usage

Comment: (Rob Bodington 06-06-21)
See 2-TJT

Comment: (Rob Bodington 04-03-26)
Changed the figure title to "Application of planned and actual activities to products."

Comment: (Rob Bodington 04-04-27)
Addressed as suggested.

Comment: (Rob Bodington 04-03-27)
Added to diagram,

Comment: (Rob Bodington 04-03-27)
activity_method_realization is part of scheme and task capability. So excluded from the usage and marked as such in the diagram

Comment: (Rob Bodington 04-03-27)
Marked as capability

Comment: (Rob Bodington 04-04-27)
Addressed

Comment: (Rob Bodington 04-04-27)
Capability number added. Figures updated.

Comment: (Rob Bodington 04-04-27)
Capability number added. Figures updated.

Comment: (Rob Bodington 04-05-05)
Yes. However, rather than include them in the capability, I have provided a description in the business concept overview and pointed out to the resource capability.

Comment: (Rob Bodington 04-05-04)
Added sections describing the use of these. Note - that Activity_status is only included for backwards compatibility with the PDM Schema. State should be used instead.

Comment: (Rob Bodington 05-03-09)
The approach documented in this capability is based on the recommendations in the PDM schema usage guide. Harmonization between the PDM schema approach and WORK_OUTPUT are required. This needs to be done in a manner that is backwardly compatible with the PDM Schema. Furthermore, this issue can only be resolved once the representing task capabilities are completed and updated to reflect the IS version of the model.

Comment: (Rob Bodington 06-06-27)
The approach has been clarified.

Comment: (Rob Bodington 05-03-09)
See SMB-1

Comment: (Rob Bodington 05-03-09)
See SMB-1

The following reference_data classes have changed:

• "start" to "Date_actual_start"
• "end" to "Date_actual_end"
• "observation_date" to "Date_actual_observation"
• "observer" to "Observer_of"
• "Activity_code" to "Activity_identification_code"

Comment: (Rob Bodington 04-09-04)
Modified text and diagram

Comment: (Rob Bodington 06-06-27)
A note has been added to explain that events are to treated as actual activities

Comment: (Rob Bodington 06-06-23)
That would be represented in the reference data itself.Alternatively business reference data could be used.

Comment: (Rob Bodington 06-06-23)
Redrawn the figures

Comment: (Rob Bodington 06-06-23)
Added

Comment: (Rob Bodington 06-06-27)
Added template

Comment: (Rob Bodington 06-06-27)
Modified

Comment: (Rob Bodington 06-06-21)
Reworded the example and included a skilled person as a required resource.

Comment: (Rob Bodington 07-02-19)
Updated

Issue raised against: representing_assembly_structure

Comment: (Tim Turner 19th Apr 2005)
Capability 1.10 was updated with the content from version 1.9

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.

Comment: (Tim Turner Oct 18th 2004)
All descriptions have been removed.

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.

Comment: (Peter Bergström 2007-04-13)
Section moved to representing_part.

Issue raised against: representing_condition

Comment: (Leif Gyllstrom 2007-05-02)
Added template assigning_condition.

Comment: (Leif Gyllstrom 2007-05-02)
Yes, and so is the case !

Comment: (Leif Gyllstrom 2007-05-02)
There might be additional characterizations that include the assignment of documents. Raised an issue GYL-1 against the AP239 long form.

Comment: (Leif Gyllstrom 2007-05-02)
This is described in the templates assigning_condition and assigning_condition_text_based respectively.

Comment: (Leif Gyllstrom 2007-05-02)

The Condition module only defines that the condition_parameter_item SELECT contains the Condition_relationship ENTITY. However, the AP239 long form includes the following:

TYPE condition_parameter_item = SELECT (Activity, Activity_method, Activity_property, Activity_property_representation, Approval, Approval_assignment, Assigned_property, Calendar_date, Certification_assignment, Classification_assignment, Condition_relationship, Contract_assignment, Date_or_date_time_assignment, Date_time, Document_assignment, Hierarchical_interface_connection, Identification_assignment, Independent_property_representation, Interface_connection, Interface_connector_occurrence, Interface_definition_connection, Managed_resource, Organization_or_person_in_organization_assignment, Product , Product_as_individual, Product_category_assignment, Product_concept, Product_definition_element_relationship, Product_version, Product_view_definition, Property_representation, Representation, Required_resource, Resource_as_realized, Resource_as_realized_relationship, Resource_event, Resource_property, Resource_property_representation, State, State_definition, View_definition_relationship); END_TYPE; (* declared in: Condition_arm *)

Issue raised against: representing_contract

Comment: (Mike Ward 2006-06-12)
Fixed.

Comment: (Peter Bergstrom 2006-01-20)
Fixed.

Comment: (Peter Bergstrom 2006-02-08)
Fixed.

Issue raised against: representing_condition_evaluated

Comment: (Rob Bodington 05-03-08)
Corrected

Comment: (Rob Bodington 05-03-08)
Corrected

Comment: (Mike Ward 2005-02-12)
Fixed.

Comment: (Mike Ward 2005-02-12)
Fixed.

Comment: (Rob Bodington 05-03-08)
Corrected

Issue raised against: representing_documents

OASIS referencing_documents (C037) is going to be deleted. Representing_documents (C005/rep_doc) includes much more than actually needed. Therefore a new template should be created in C005 to represent document when referenced.

Proposal: NEW template represent_document_without_view (rep_doc_w_out_view), containing Document and Document_version with identifiers on both and optional classification on Document without document_assignment.

Naming consideration: Is it possible to name the template referencing_document_version (ref_doc_vers) instead of rep_doc_w_out_view?

It should be possible to identify a type of document by classification.

Proposal: Add optional classification to Document for all templates related to representing_document.

It should be possible to assign a document, independent of its views, to product and support data.

Proposal: NEW template assigning_referenced_document (asg_ref_doc), containing Document and Document_version with identifiers on both and optional classification on Document + Document_assignment with classification.

Note: differs from DVN-15 because of document_assignment.

It is necessary to reference parts of a document content, e.g. chapter, section, table, figure, page number etc. Entity Partial_document_assignment is missing from OASIS C005.

Proposal part1: The entity Partial_document_assignment must be added to C005 or in a new capability.

Proposal part2: NEW template Assigning_partial_document (asg_partial_doc), consisting of Partial_document_assignment with classification + Document and Document_version with identifiers on both and optional classification on Document (ref to new template DNV-15).

Comment: (Tim Turner on behalf of UK MoD TES/ILS and Eng Pol under TLSS Development Programme. Dec 15 2006)
Document properties are handled by the assigning_document_properties capability and is refered to within the section document properties.

Comment: (Tim Turner on behalf of UK MoD TES/ILS and Eng Pol under TLSS Development Programme. Dec 15 2006)
Diagrams were drawn prior to decision to use External_class. Will be removed/updated.

Comment: (Tim Turner on behalf of UK MoD TES/ILS and Eng Pol under TLSS Development Programme. Dec 15 2006)
They can be represented as a number of document_definitions which are defined against a particular document_version according to the chapters/sections required for the document. Each definition has an .id (labeled through reference data) which is used to provide the section/chapter number. Sequential sections/chapters can be represented through the document_definition_relationship mechanism (ref data in this case would be "sequential". For the case where a chapter needs to be broken down into separate sub-sections, or perhaps by pages, "decomposition" should be used. This can be used to provide the logical structure of a document. The name of each section/chapter can also be (optionally) provided through reference data, plus any additional context information as additional text. In addition, each definition may be represented as individual files (digital files if using digital documents, else hardcopy components of physical_documents). If the different chapters/section/pages etc.. are defined in separate files, then a single document_definition can be used but with many component files. The different sections can then be related through the use of the file_relationship entity using the "sequential" or "decomposition" reference data as required.

Comment: (Tim Turner on behalf of UK MoD TES/ILS and Eng Pol under TLSS Development Programme. Dec 15 2006)
Template parameters have now been updated. Figures and path added.

Issue raised against: representing_environment_typical

Comment: (Rob Bodington 04-05-07)
Corrected

Comment: (Rob Bodington 04-05-07)
Corrected

Comment: (Rob Bodington 04-05-07)
Corrected classifications. State_definition classified as "State_of_environment" Applied_state_definition_assignment classified as "Operating_environment"

Comment: (Rob Bodington 04-05-07)
Corrected

Comment: (Rob Bodington 04-05-07)
Corrected

Comment: (Rob Bodington 04-05-07)
The capability is no longer dependent on representing_state_type capability As all that is required from the state_definition module is state_definition. It makes no sense to typical environments. Any environment can follow on from any other environment.

Comment: (Rob Bodington 04-09-29)
Changed

Issue raised against: representing_evolution_of_property_values

Comment: (Peter Bergström 2006-06-08)
This harmonization has been carried out.

Issue raised against: representing_justification

Comment: (Peter Bergström 2007-02-02)
Two templates have been created: assigning_justification, and assigning_justification_support_item.

Comment: (Peter Bergström 2007-02-02)

Simple textual descriptions of the justification has been added through template assigning_descriptor. Further supportive information could be assigned to a justification through justification_support_item, which may relate a document in a specific role to the justification.

See also AP239 issues, issue RBN-5 2007-02-01.

Comment: (Peter Bergström 2007-02-02)

Simple textual descriptions of the justification has been added through template assigning_descriptor. Further supportive information could be assigned to a justification through justification_support_item, which may relate a document in a specific role to the justification.

See also AP239 issues, issue RBN-5 2007-02-01.

Comment: (Rob Bodington 04-09-29)
The document providing the reason for the justification should be assigned through justification_support_item, rather than using document assignment

Comment: (Rob Bodington 04-09-29)
Changed

Issue raised against: representing_life_cycle_opportunity

Issue raised against: representing_location

The capability representing_location should be merged with representing_product_location. The capability should have a template for assigning each of the different types of location. E.g. assigning_address_location, assigning_organization_location etc.

The instruction to remove the Organzation entity is incorrect. It is required by the ENTITY Organization_based_location_representation.

A template is required to relate a product based location to its parent product.

Proposal: Add NEW template representing_product_based_location (rep_p_based_locn), containing Product_based_location_identification with one identifier and one classification.

The general issue about templates at entity granularity arises and it needs to be considered.

Representing_location (C027) and assigning_location (C049) are represented as two differenet capabilities.

Proposal: Consider integrating them into representing_location (C027) and use assigning_location as a template.

Comment: (Mike Ward 2004-10-19)
Done

Comment: (Rob Bodington 06-06-23)
The template has been deleted

Issue raised against: representing_observation

Issue raised against: representing_parts

Comment: (Tim Turner 19th Apr 2005)
Capability 1.19 was updated with the content from version 1.17

Comment: (Tim Turner June 2004)
Accepted. Done.

Comment: (Tim Turner June 2004)
Discussed. Rejected. Category to remain.

Comment: (Rob Bodington 04-09-30)
The categorization of products should be done using reference data, not product_category. There is a ballot comment against AP239 to this affect.

Comment: (Tim Turner Oct 18th 2004)
Issue NO 23 was discussed and rejected.

Comment: (Tim Turner June 2004)
Accepted. Completely re-worded all relevant sections.

Comment: (Tim Turner June 2004)
Accepted. Processor info removed.

Comment: (Tim Turner June 2004)
Accepted. Done.

Comment: (Tim Turner June 2004)
Accepted. Done.

Comment: (Tim Turner Oct 18th 2004)
There are many things that can be assigned to a part. However, these are not part of the representation of the part itself. This should instead be handled by the capability Assigning_approvals. Such aspects were removed from the early incarnations of this model.

Comment: (Tim Turner Dec 13th 2006)
Comment: (Tim Turner Dec 13th 2006) A where rule in the EXPRESS requires the use of product_cateogry. This was intended both for part categorisation and assembly/detail information. The latter is useful within exchange sceanrios when a complete assembly/decomposition view of the product is not available - just the part. Resolution: The value of product_category.name attribute shall be 'part' (Note: lowercase is mandatory). The base reference data for instances of Part using External_class shall be "part_category" for which sub classes can specify different types of parts. In order to infer whether the part is itself decomposable, or a component within a larger assembly, we either need to split the base reference data "part_category" into "part_assembly_category" and "part_detail_category", so that all classifications shall fall into one or other categories; Or, alternatively, we can recommend a second, additional classification which provides the same level of information but is separate from the sub-classification hierarchy. I favour the use of a second, independant classification. This allows us to deprecate the use of product_category_hierarchy entity By default, I recommend that every Part is inferred to be a detailed, individual part that is not part of any defined assembly structure or defined decomposable structure. Where this is not the case, and in addition to the mandatory instance of product_category ('part'), the product_category should be classified using External_class - which shall be set to "assembly".

Comment: (Tim Turner Aug 16th 2005)
Resolution: Correspondance:- -----Original Message----- From: Tim Turner Sent: 16 August 2005 15:35 To: DEXS-PLCS-OASIS (E-mail) Subject: Representing_parts C002 Issue RBN-9 (the last one for C002!) In the interest of visibility my response + comments to the issue are provided below; Issue: RBN-9 by Rob Bodington (05-01-13) minor_technical issue The capability should emphasize that product_category is only used to distinguish between the different subtypes of Product defined in AP239. and that the value of product_category should be 'part' in this capability. More specific types of products, such as Oil filter as a type of Part should be specified by means of Classification_assignment, thus allowing the use of a class library via External_class. The External_class is "part_category" for which there are sub classes specifying "Oil filters" etc. Given the use of an external class library for the representation of product categorization, there is no role for the product_category_hierarchy entity and it should be removed from the capability. Editor's Response: Product_category is required by the model for compatibility with the PDM schema. I have no problem in removing product_category_hierarchy from the model, nor using the External_class to represent "part_category" or sub classes thereof, provided I can ascertain the same level of information without them. I would like to point out (IMHO) that the accepted practice in the use of Product_category has been to; a) categorise an item to be a 'part' - which is covered by the discussion above, but b) to also indicate whether the part is an 'assembly' or a 'detail' (i.e. not having parts of it's own). The latter fact is established through an additional Product_category + related to the first through the product_category_hierarchy relationship. In order to achieve the same level of information, we either have to *assume* that this will be specified explicitly using an assembly structure, or we need to add a second classification to indicate this fact. We should like to know whether a part is actually an assembly itself, or a single piece part, without recourse to the full explicit representation of the assembly model (if present or provided). Else (IMHO) we have to create some guidance to state that a part is always to be regarded as a single piece-part (detail) unless there is an assembly model defined for it (in which case it ceases to be a single part). My point is that we may not always have the assembly model of a part. Comments? regards, Tim

Comment: (Peter Bergström 2007-03-28)
I have been editing the representing_parts capability, and made a lot of changes. Most of these are (I hope) not significant for what the capability specifies, but more in line with updating it with the development of DEXlib over the years – templates and so on. However, I did not include anything about a part being identified as an “assembly” or “detail”.
I have tried to catch up with previous discussions in this matter, and I think what I have done now boil down to the fact that if you see a part that is not a parent (through Next_assembly_usage), you treat it as “detail” until you find a Next_assembly_usage that relates to it as “relating”, and then you change your mind. I have asked the people I have contact with, and none of them see any need to know whether a Part is an assembly or a detail until you start building structures, and then it is obvious. And even if you don’t have the constituents of a Part that is really an assembly, what good does it make to you to know that somewhere else an assembly ought to exist for this part, but I don’t have it? Therefore, I kind of have avoided the entire discussion, and it seems to work.
I just wanted you to look at this specifically, since you (as far as I can see) is the one that have advocated the need for this categorization of parts the most. Is this categorization really something that we must have? What happens if we just ignore it, and assume that all parst are details until we find out the contrary? There is still an open issue regarding this, and I would like to close it, so if there is such a real need somewhere, I would like to understand that now by an example.

Comment: (Peter Bergström 2007-04-13)
Closed due to no further information.

Comment: (Tim Turner Aug 16th 2005)
Resolution: Yes, the classes shall be changed accordingly. Correspondance:- -----Original Message----- From: Tim Turner Sent: 16 August 2005 13:22 To: DEXS-PLCS-OASIS (E-mail) Subject: Representing parts Issue RBN-10 In the interest of visibility My response + comments to the issue are provided below; Issue: RBN-10 by Rob Bodington (05-02-16) minor_technical issue The classes have changed in the reference data. Part_type_code is now Part_identification_code Version_code is now Version_identification_code Id_owner is now Owner_of The classes used in the capability should either be changed as above, or the reference data should be updated. Editor Response: I agree, the classes shall be changed accordingly. regards, Tim

Comment: (Tim Turner Aug 16th 2005)
Resolution: Correspondance:- -----Original Message----- From: Tim Turner Sent: 16 August 2005 16:42 To: DEXS-PLCS-OASIS (E-mail) Cc: Gordon Robb Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 Hi Gordon, are saying that version relationships (aka product_version_relationships) are not necessarily the only mechanism needed to distinguish between versions? I just want to acertain whether you are raising an issue against adding version relationships to this capability. cheers, Tim -----Original Message----- From: Gordon Robb Sent: 16 August 2005 10:08 To: 'rob.bodington@eurostep.com'; Gordon Robb; Tim Turner; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 Rob, Your 1st para requires a slight amendment "All I am saying is that we need to (and can) be able to represent/model the fact that a part version can be related to another part version. In other words I want to run a query on a database along the lines of I have Part XYZ at version 3, What are the other versions of part XYZ?" This then caters for the fact that common items for multiple customers are identified by a means of identifying the correct version for each customer. e.g. 75A450123-2001 - FAIRING = AV-8B CUM 1 thru 125 ; 75A450123-2003 - FAIRING = GR5 CUM 1 thru 23; 75A450123-2005 - FAIRING = SAV-8B CUM 1 THRU 14 75A450123-2007 - FAIRING = AV-8B CUM 126 thru 167 My query to the 'database would be "Find all versions of 75A450123................ The dash number in this case is the means of versioning the fairing. I cannot ever remember seeing any Version 1 or 2 or 3 on drawing sets associated with the Aero world It should be noted that the PLCS TD in which we are supposed to be adhering to states " product identifier" Definition A name or alphanumeric identifier, used to designate a part or assembly, of the same configuration, and to differentiate it from all other products. Note These identifiers may include a supplementary identifier used to distinguish one of several sequentially created configurations of a product from the previous configuration of the same product (i.e. revision or version). Gordon -----Original Message----- From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 16 August 2005 09:09 To: 'Gordon Robb'; 'Tim Turner'; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 Gordon All I am saying is that we need to (and can) be able to represent/model the fact that a part version is related to a previous part version. In other words I want to run a query on a database along the lines of I have Part XYZ at version 3, What was the previous version of part XYZ? It is common practice not to version parts, but to renumber them. Hence we need to (and can) be able to represent/model the fact that a part is derived from a previous part. This information does not necessa[Gordon Robb] B rily require assembly information. That's all. Regards Rob -----Original Message----- From: Gordon Robb [mailto:gor@lsc.co.uk] Sent: 16 August 2005 07:36 To: 'Rob.Bodington@eurostep.com'; Tim Turner; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 Rob, You have to be careful in your statement 'fact that a version of a part follows on the previous version' - there can be occasions were there is concurrently several versions of the part in production dependent on the customer base. Gordon -----Original Message----- From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 15 August 2005 16:16 To: 'Tim Turner'; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 I don't believe that there is an issue in using an entity in more than one capability. -----Original Message----- From: Tim Turner [mailto:tjt@lsc.co.uk] Sent: 15 August 2005 15:54 To: 'Rob.Bodington@eurostep.com'; Tim Turner; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 Fair enough. But is there an issue with using product_version_relationship within more than one capability like this? If this would be an issue, I'd propose to move the subtype as well to rep_parts, else, I'd just move the super type. regards, Tim -----Original Message----- From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 15 August 2005 04:25 To: 'Tim Turner'; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 My motivation for writing the comment was that I want to represent the fact that a version of a part follows on the previous version. Initially this has nothing to do with an assembly of parts - it is just about the part. Similarly if a Part is derived from another part, I want to relate the two. Again, this has nothing to do with an assembly. Hence my suggestion that these representations should be in the rep_part capability. Regards Rob -----Original Message----- From: Tim Turner [mailto:tjt@lsc.co.uk] Sent: 12 August 2005 18:35 To: DEXS-PLCS-OASIS (E-mail) Subject: [plcs-dex] Representing parts - Issue: RBN-11 In the interest of visibility My response + comments to the issue are provided below; RBN-11 by Rob Bodington (05-02-21) minor_technical issue The relationship between different version(s) should be described in this capability, not "representing_assembly_structure" (C003). 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. TJT Response: Relationships between parts, part versions and view_definitions are not currently described within Representing_parts. They are described within representing_assembly_structures as these relationships are used to define the assembly structures and how those structures might change if different versions of a part are used. However, it is possible to include product_version_relationship in this capability, but it would then exist in both. This is because supplied_part_relationship (a subtype) would + I believe should, stay within C003. Though I could be persauded. I agree with the use of the classification and the ref data derived from the PDM schema. Comments? regards, Tim

Comment: (Peter Bergström 2007-03-28)
This was already fixed.

Comment: (Tim Turner Aug 16th 2005)
Resolution: Yes, representing_parts will be harmonised with representing product as individual, and use the same classification approach. Correspondance:- -----Original Message----- From: Tim Turner Sent: 12 August 2005 12:57 To: DEXS-PLCS-OASIS (E-mail) Subject: Representing parts - Issue: RBN-12 In the interest of visibility My response + comments to the issue are provided below; Issue: RBN-12 by Rob Bodington (05-02-24) minor_technical issue Resolution: Accept. Status: open The description of the view definition context should be harmonised with representing product as individual, and use the same classification approach. TJT Response: I agree in principle. The impact is that view_definitions can only be processed on import with reference to traversing the sub/supertype hierarchy contained within the RDL. regards, Tim

Comment: (Tim Turner Aug 15th 2005)
Resolution:Yes, the part_version and Part view definition shall have an assigned id (and the relevant classification to go with it). Correspondance:- -----Original Message----- From: Tim Turner Sent: 15 August 2005 11:41 To: 'Per-Åke Ling'; Tim Turner Cc: DEXS-PLCS-OASIS (E-mail) Subject: RE: [plcs-dex] Representing parts Issue RBN-13 Per, thanks for your effort to describe this problem. The practice of dis-associating the attributes from entities in PLCS (such as .id) creates a challenge for us - especially when implementing these ideas. There are strengths and weaknesses with every approach. The example below that you sketch below indicates some ambiguity in deciphering the id of the part (since there is more than one) given a set of part_versions which all have the same org.id. The date/time stamp is of course optional. Normally (!) in an exchange file, the part_version will specify the part to which it is related (so your arrows might need to be reversed). Then the part attributes e.g. part.id can usually be determined. However, in PLCS these attributes are empty, replaced by identifiers assigned separately to the part. Your example shows two such identifiers "4711" and "ABC". The issue that this raises is how to determine which one is to be used and in which situation