PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.2 Cause: The description "The Activity_authorization_query selects Activity objects." is wrong; no Activity_authorization_query is involved here. Furthermore, the semi-formal UML definition of the Activity_query is missing. New Specification Text: New description: The Activity_query selects Activity objects. The semi-formal UML definition of the Activity_query has to be added.

Correct, change as proposed in summary.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.23 and Figure 9.39 Cause The location step property_value_association_step is unable to select instances of Property_value_representation since inverse is implicitly set to false. Furthermore, location step property_value_representation_step is unable to select instances of Property_value since inverse is implicitly set to false. Finally, location step global_unit_step cannot select instances of type Unit since the named relationship global_unit is defined in Property_value_representation, but the result-set of the preceding location step does not contain any Property_value_representation at all. For consistency reasons the names of the mentioned location steps shall be adjusted. New Specification Text: The following is a literal description of the changes to be made in figure~9.39. The location steps property_value_association_step and property_value_representation_step must have the attribute inverse set to true in order to select instances of Property_value_representation and Property_value properly. Furthermore, the location step global_unit_step has to be the next step of location step property_value_association_step to select Unit instances by the named relationship Property_value_representation.global_unit. For consistency reasons location step property_value_association_step has to be renamed into inverse_property_value_representation_step (since the inverse location step selects instances of type Property_value_representation) and property_value_representation_step has to be renamed into inverse_property_value_step (since the inverse location step selects instances of type Property_value).

Accepted as summarized.

In the informational model, the object "Document_file" shall have the annotation: <info:base name="Identifiable"/> since it has an identifying attribute 'id' and potentially an 'id owner'. This annotation was part of the previous informational model => should be introduced again.

Edit InformationalModel.xsd as described.

The last lines in the InformationalModel.xsd: <info:javaInfo javaBaseClassExtended="de.partmaster.xml.bind.adaptable.AdaptableJAXBObjectImplExtended"/> <info:javaInfo javaBaseClass="de.partmaster.xml.bind.adaptable.AdaptableJAXBObjectImpl"/> <info:javaInfo javaBaseName="InformationalModel"/> <info:javaInfo javaBasePackage="de.partmaster.plm.informational.model"/> shall be removed, since they are specific to the company Part Master GmbH

Edit InformationalModel.xsd as described.

In the informational model, explicit_transformation shall be renamed to explicit_transformation. Like all other objects, the first character shall be in uppercase

The current InformationModel.xsd is already correct as noted in the summary. But, there is a problem with the explanation in Chapter 8.5.1.15 which shall not be a heading.

The function Get_download_URL shall be enhanced to download multiple files at once Proposal to change the declaration from: get_download_URL(in_file_uid UID, properties: ...): URL to: get_download_URL(in_file_uid UID[0..*], properties: ...): URL[0..*] The value of the properties apply to all files (I they shall get different values for the different files, single calls to get_download_URL with a single file shall be done). The number of URLs shall be equal to the number of given file_uids. If semanticaly defined by [0..*], the order of the URLs shall be the same as the order of the in_file_uids.

Accepted as proposed.

The type Axis2_placement_3d shall be removed from the class PLM_container, since its supertype Axis2_placement is already part of the PLM_container.

Disposition: See issue 11618 for disposition

There is a problem with Cartesian_point element. In InformationalModel it is included in the PLM_container but in its inheritance it does not inherit from PLM_root_object. Its grandparent inhertis from PLM_object. All other objects that reside directly under PLM_container inherit from PLM_root_object.

Accepted as proposed. Change information model object inheritance as described in summary

In Figure 8.16 (PLM_base) both associations PLM_message.PLM_context and PLM_message.PLM_core_container shall be denoted as compositions (since they are defined as such in 8.1.1.4) instead of simple directed associations

In Figure 8.16 (PLM_base) both associations PLM_message.PLM_context and PLM_message.PLM_core_container shall be denoted as compositions (since they are defined as such in 8.1.1.4) instead of simple directed associations

The parameters Add_period, Add_start_definition and Add_end_definition are missing (refer to the WSDL). Add_concerned_organization should be also added as parameter and in the WSDL. More generally, the handling of WSDL-Attribute of kind: type="xsd:IDREFS" minOccurs="0" is not handled in an homogen way throughout the specification: . some of them are retrieved by a dedicated specific_query (for example work_request_scope_query) . some of them are retrieved automatically when the object is retrieved (for example Associated_aproval_query always retrieve is_approved_by and scope) . some of them are retrieved if some parameter of kind add_... is set to TRUE (for example in effectivity_query) . some of them are not retrieved at all, since they are not handled in the 3 ways described above. These are for example: activity.concerned_organization activity.supplying_organization cartesian_coordinate_space.unit_of_values ddid.additional_context document_property.languages document_file.external_id_and_location product_component.is_influenced_by product_component.is_relevant_for product_function.is_relevant_for property.allowed_unit work_request.notified_person Proposal: define add_parameter (analog to effectivity_query) for simple objects which do not imply the retrieval of too many objects. For the other ones: define a dedicated specific query that may be combined with further queries to complete the result

Add the requested three attributes Add_period, Add_start_definition and Add_end_definition to the signature of the Effectivity_query.

New query Product_identification_query to select product_identification objects. Use case at DaimlerChrysler: select existing product reference configuration by name. <xs:complexType name="Product_identification_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Id" type="xs:string" minOccurs="0"/> <xs:element name="Id_scope" type="xs:string" minOccurs="0"/> <xs:element name="Name" type="xs:string" minOccurs="0"/> <xs:element name="Name_language" type="xs:language" minOccurs="0"/> <xs:element name="Version_id" type="xs:string" minOccurs="0"/> <xs:element name="Associated_product_class" type="xs:string" minOccurs="0"/> <xs:element name="Classification_role" type="xs:string" minOccurs="0"/> <xs:element name="Classification_id" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> Dito for the subtype product_specification: product_specification_query with an additional parameter to restrict the selection through one or many specification id's

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

The operations get_download_URL and get_upload_URL may not be combined with other operations like Query, Write, Import and Export. They currently support only one file uid. Example: if a complete assembly structure shall be selected via a recursive query, together with the download of all referenced files, it is currently necessary to call get_download_URL as many times as there are files referenced from the assembly structure... Proposal to combine Query and Download through a new parameter in Associated_file_query: <xs:complexType name="Associated_file_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="download" type="xs:boolean" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> If download=TRUE, the corresponding file will be downloaded and the URL will be placed in document_location_property.location_name

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

New operation set_product_identification to activate a product configuration. Functionality: the product configuration defined through the given product_identification will be activated, so that the following query operations return only the objects that are provided within this product configuration. In the same way, during write or import operations, the incoming data will be checked according to the activated product configuration, before being written or imported. Input parameter is the uid of a product_identification or product_specification object. Return value is nothing (when OK) or an exception. <wsdl:operation name="set_product_identification"> <soap:operation soapAction="" style="rpc"/> <wsdl:input> <soap:header message="Session_id_header" part="session_id" use="literal"/> <soap:header message="Signature_header" part="signature" use="literal"/> <soap:body use="literal" namespace="http://www.omg.org/PLMServices1.0/PLM_connection#query"/> </wsdl:input> <wsdl:output> <soap:body use="literal" namespace="http://www.omg.org/PLMServices1.0/PLM_connection#query"/> </wsdl:output> <wsdl:fault name="Pid_fault"> <soap:fault name="Pid_fault" use="literal" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </wsdl:fault> </wsdl:operation>

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

Neue query Activity_resolved_request_query to traverse from activity objects to work_request objects via the attribute resolved_request. Since this attribute is mandatory but aggregate, it is currently not possible to query all its values if all the referenced work_requests are not part of the query result. <xs:complexType name="Activity_resolved_request_query"> <xs:complexContent> <xs:extension base="Query"/> </xs:complexContent> </xs:complexType>

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

New Query Event_reference_context_offset_query to traverse from event_reference objects to general_organizational_data_select objects via the attribute event_context, as well as to duration objects via the attribute offset. Since these attributes are optional, then can currently not be traversed. <xs:complexType name="Event_reference_context_offset_query"> <xs:complexContent> <xs:extension base="Query"/> </xs:complexContent> </xs:complexType>

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

New Query Effectivity_start_end_period_definition_query to traverse from effectivity objects to event_or_date_select objects via the attributes start_definition and end_definition, as well as to duration objects via the attribute period. Both aspects are mutually exclusive, i.e. an effectivity has either start/end_definition or a period. Since these attributes are optional, then can currently not be traversed. <xs:complexType name="Effectivity_start_end_period_definition_query"> <xs:complexContent> <xs:extension base="Query"/> </xs:complexContent> </xs:complexType> <xs:complexType name="Effectivity_assignment_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Role" type="xs:string" minOccurs="0"/> <xs:element name="Effectivity_indication" type="xs:boolean" minOccurs="0"/> <xs:element name="Element_type_name" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

New Query Effectivity_assignment_query to traverse from effectivity_element_select objects via effectivity_assignment objects to effectivity objects: <xs:complexType name="Effectivity_assignment_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Role" type="xs:string" minOccurs="0"/> <xs:element name="Effectivity_indication" type="xs:boolean" minOccurs="0"/> <xs:element name="Element_type_name" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

Associated_file_query currently returns only four of the five document_properties: document_creation_property is missing => should be added in the query definition

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

New Query 'Activity_authorization_query' to traverse from activity objects zo work_order objects via the attribute 'authorization'. Since this attribute is optional an INVERSE, it is currently not possible to traverse it. <xs:complexType name="Activity_authorization_query"> <xs:complexContent> <xs:extension base="Query"/> </xs:complexContent> </xs:complexType>

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

New parameter 'Id_scope' in Work_request_query, like currently in all queries that have an Id parameter defined unique only within the scope of an organization: <xs:complexType name="Work_request_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> ... <xs:element name="Id_scope" type="xs:string" minOccurs="0"/> ... </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

Introduction of a new 'specific Query' 'work_order_query' to select work_order objects, as needed by Change Management Scenarios: <xs:complexType name="Work_order_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Id" type="xs:string" minOccurs="0"/> <xs:element name="Id_scope" type="xs:string" minOccurs="0"/> <xs:element name="Work_order_type" type="xs:string" minOccurs="0"/> <xs:element name="Version_id" type="xs:string" minOccurs="0"/> <xs:element name="Classification_role" type="xs:string" minOccurs="0"/> <xs:element name="Classification_id" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

Associated_file_query currently returns only four of the five document_properties: document_creation_property is missing => should be added in the query definition

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

In document mantis/dtc/05-03-08 from the PLM Services 1.0 specification, chapter 8.12 (Generic Queries Conformance Point), a new query 'activity_authorization_query' should be included to enable the traversal from activity objects to the work_order objects which are the authorization of the activity objects, having none parameters.

This is a leftover from the PLM 1.x RTF when it was out of scope. The issue was then addressed by the PLM Services 2.0 Submission.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

In document mantis/dtc/05-03-08 from the PLM Services 1.0 specification, chapter 8.12 (Generic Queries Conformance Point), a new query 'activity_resolved_requests_query' should be included to enable the traversal from activity objects to the work_request objects which are the resolved request of the activity objects, having none parameters.

This issue is a leftover from the PLM 1.x RTF, when the requested change was out of scope for an RTF. The issue was then forwarded to, and addressed by the PLM Services 2.0 submission team.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

In document mantis/dtc/05-03-08 from the PLM Services 1.0 specification, chapter 8.12 (Generic Queries Conformance Point), a new query 'work_order_query' should be included to enable the selection of work_order objects, having following parameters: id: String [0..1] work_order_type [0..1]

This issue is a leftover from the PLM 1.x RTF, when the requested change was out of scope for an RTF. The issue was then forwarded to, and addressed by the PLM Services 2.0 submission team.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

XSD files lack default namespace

The RTF agrees that the xsd files require corrections of the namespace declarations to validate. The RTF takes this opportunity to convert the XSD files to the new namespace convention of the OMG. This requires corresponding changes in the WSDL files too.

some numbering mismatch in chapter 7.7 7.7.11.1 shall be not Classes but Class Address 7.7.10.1 shall be not Classes but Class Alias_identification 7.7.9.1 shall be not Classes but Class Cost_property 7.7.8.1 shall be not Classes but Class Classification_association 7.7.7 shall be 7.7.6.24, subsection heading Heading4 become subsection 7.7.6.1 shall be not Classes but Class Accuracy 7.7.5.1 shall be not Classes but Class Digital_document 7.7.4 shall be deleted 7.7.2.1 shall be not Classes but Class Application_context 7.7.1.1 shall be not Classes but Class PLM_container

No Data Available

First sentence in Chapter 7.4.3.1: "An instance of type Document...", not "...Item..."

No Data Available

Person_in_organization_relationship is element of AP but not of PLM Services 1.0. Use explanatory text as in AP214

No Data Available

figures missing: Figure 2-18 Property Figure 2-19 Property value Figure 2-20 Simple property Figure 2-21 Material property Figure 2-22 Alias identification Figure 2-23 Authorization - Person and organization Figure 2-24 Authorization - Approval Figure 2-25 Authorization - Date and time

No Data Available

Align simple property assignment mechanism with STEP AP214 maintenance version. Use the following STEP EXPRESS constructs: – new in AP214 ENTITY simple_property_association; described_element : simple_property_select; specified_value : property_value; value_type : STRING; END_ENTITY; – already in AP214 ENTITY string_value SUBTYPE OF (property_value); value_specification : string_select; END_ENTITY; TYPE simple_property_select = SELECT ( item_property_select, process_property_select ); END_TYPE;

No Data Available

Date and Time types shall be mapped according to ISO 8601. Where possible, built-in types shall be used: XML model: * xs:date for date_time.date * xs:time for date_time.time

No Data Available

Definition of project is wrong with respect to project.affected_product_class attribute. But the maintenance version of STEP AP214 proposes the split into project and project_assignment with structure corresponding to the following STEP model: ENTITY project; id : STRING; name : string_select; description : OPTIONAL string_select; actual_start_date : OPTIONAL date_time; actual_end_date : OPTIONAL date_time; planned_start_date : OPTIONAL event_or_date_select; work_program : SET [0:?] OF activity; planned_end_date : OPTIONAL period_or_date_select; END_ENTITY; ENITY project_assignment; assigned_project : project; role : STRING; is_applied_to : SET [1:?] OF project_information_select; END_ENTITY;

No Data Available

Organization_relationhip is element of AP214 but not of PLM Services 1.0 This element describes relationships between organizations and ist hierarchical compounds like departments. This organizational hierarchy shall be described in PLM services. Use explanatory text as in AP214

No Data Available

Work_request and Work_order are Root_objects and are usually result of Start_Node_query. It would be much better to support specialized Work_request_query and Work_order_query for this purpose in the PDTnet queries conformance point and in the Web services specification.

No Data Available

New element type required: Work_request_relationship models relations of Work_request in analogy to Activity_request_relationship with relating as containment relationship in XML and related as IDREF to work_request Motivation: For development partners different work_request numbering schemes are in effect which shall be modelled. STEP EXPRESS model for the new element: ENTITY work_request_relationship; related : work_request; relating : work_request; relation_type : STRING; description : OPTIONAL string_select; END_ENTITY

No Data Available

Clarify "Signature" attribute of PLM_session_context type

No Data Available

Examples (incl. SOAP responses) for object_factory, get_connection, close, write, delete, export_data, import_data and exceptions structures shall be appended

No Data Available

The "predicates" data type shall be clarified and described in more detail in section 8.9.

No Data Available

The predicates data type shall be clarified and described in more detail.

No Data Available

Rename insert-Operation into import_data, which reflects better the semantics of the insert operation as described in section 8.7.3. Consequently, rename export-Operation into export_data for consistency.

No Data Available

PLM_message[0..*] type as defined with the write-Operation in section 8.7.1 shall be further detailed to capture more specific information for all methods in PLM_connection interface. Potentially, more subtypes are required to signal error situations. Therefore, this type shall be defined in a separate section.

No Data Available

Delete-Operation, as described for the PLM_connection interface in section 8.8.4 shall return an error message, potentially a PLM_message[0..*] type.

No Data Available

To define the semantics of the queries of the new high level
queries conformance point (issue 7828) we need a new query
to ask for placement information of Assembly_component_relationship objects.

<xs:complexType name="Assembly_component_placement_query">
<xs:complexContent>
<xs:extension base="Query"/>
</xs:complexContent>
</xs:complexType>

No Data Available

The enumerations of the start and destination types in the
specification of the queries of the PDTnet queries conformance point
should be replaced by grouping interfaces of those types.

No Data Available

The specific conformance Point should define queries for resolving Alias_identifications.
Some of these queries are already defined,
for instance Item_query, Item_version_query, Design_discipline_item_definition_query.
But some queries are missing,
for instance Item_instance_query, Specification_query, Product_class_query.

No Data Available

To define the semantics of the queries in the new high level
conformance point suggested in issue 7828 we need a new
construct for queries, which execution depends
on some conditions. Such condition could be:

• if a boolean value is true
• if a boolean value is not true
• if a value is set
• if a value is not set

<xs:complexType name="Conditional_query">
<xs:complexContent>
<xs:extension base="Query">
<xs:sequence>
<xs:element name="Attribute_is_true" type="xs:boolean" minOccurs="0"/>
<xs:element name="Attribute_is_not_true" type="xs:boolean" minOccurs="0"/>
<xs:element name="Attribute_is_set" type="xs:string" minOccurs="0"/>
<xs:element name="Attribute_is_not_set" type="xs:string" minOccurs="0"/>
<xs:element name="Query" type="Query"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

No Data Available

Section 8.9 should be a subsection of 8.8
Change 8.9 to 8.8.1
This automaticly changes old subsections of 8.9 to new subsections of 8.8.

No Data Available

Optional attributes should be defined by a multiplicity of [0..1] instead of the label <<optional>>.

No Data Available

It would be a good generalization of the new Relationship_queries
suggested in the issues #8000, #8004, #8006 and #8009,
to introduce an common base class for the relationship queries
with the attributes relation_type and inverse.
If the boolean attribute inverse is set to TRUE, the derived
Relationship has to be traversed in inverse direction
with respect to the default direction defined in the informational model.

No Data Available

The attribute identifier_name in class Identifier_predicate is redundant.
The predicate is only relevant for PLM_objects which have an Alias_identification.
If the PLM_object is an instance of Document the name of the identifier attribute is "document_id".
If the PLM_object is an instance of Physical_instance the name of the identifier attribute is "lot_id".
If the PLM_object is an instance of Document_type_property the name of the identifier attribute is "document_type_name".
If the PLM_object is an instance of Approval_status the name of the identifier attribute is "status_name".
In all other cases the name of the identifier attribute is "id".

No Data Available

Add missing query Work_request_relationship_query in order to allow searching for specific Work_request objects related by a Work_request_relationship object starting at an given work_request object Proposed solution: <xs:complexType name="Work_request_relationship_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Relation_type" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available

beeing in charge of the security chapter of the PLM Services, we overworked the chapter 10.7 according to our latest experiences.
This overwork actually does not invalid any statement of the previous version of the security chapter, but we completed it with more examples, a picture and some additional explanations.

Since it would be very difficult to describe all changes in single issues, we prefer to send it the whole pack as 'one' issue, which is the attached MS Word document. All changes are documented using MS Word features, so that the differences from the old to the new text are clearly visible.

New text for chapter security

To align the PLM Services Informational Model with the STEP AP 214 Data Model
the Attribute "description" of type "Translatable_string" should be added
to the entities "Document_file" and "Person_in_organization_relationship".

Add this new attributes added in STEP AP214 Rev 3.

Document mantis/07-03-01
Chapter 8.9.1

Specification of class Person_in_organization_relationship is missing
for full STEP AP214 CC21 conformance.

Add Person_in_organization_relationship in Chapter 8.9.1

PLM Services 2.0
Document mantis/07-03-01
Chapter 9.4.7

Specification of Relationship_predicate

The Specification of the Relationship_predicate is not precise and need some bug fixes and additions:

1. ALL constraints must be fullfilled.
2. The attribute 'predicate' is now named 'related_object_predicate'
3. A new constraint for the attribute 'relating_object_predicate' has to be added.

Here is the new Text:

An object fulfill a Relationship_predicate constraint if it fulfill all the following partial constraints:

• The object fulfill all the Predicate instances referenced by the relationship relating_object_predicate of the Relationship_predicate.

• The object is related with another object that fulfill all the Predicate instances referenced by the relationship related_object_predicate of the Relationship_predicate.

• If the value of the attribute inverse of the Relationship_predicate is not true and if the attribute role_name is set, the role name of the other object in the relationship must be equals to the value of the attribute role_name of the Relationship_predicate.

• If the value of the attribute inverse of the Relationship_predicate is true and if the attribute role_name is set, the role name of this object in the relationship must be equals to the value of the attribute role_name of the Relationship_predicate.

• If the attribute role_declaring_type_name is set, the relationship must be defined in a type which name is equals to the value of the attribute role_declaring_type_name.

Disposition: See issue 11202 for disposition

E1. Section "0.5 Proof of Concept"

If this section gets transferred to the Final Adopted Specification, please fix the following:

E1.1 Every instance of "it's" (with an apostrophe) should be "its" (no apostrophe). 3 instances.

E1.2 "... evaluated in a interaction scenario ..." should be "... evaluated in an interaction scenario ..."

E2. Section "0.8 Edit Directions Against PLM Services V1.0 (dtc/2005-03-08)"

As we discussed at the AB meeting, this title should be "Changes from PLM Services V1.0 (dtc/2005-03-08)" (or some similar language).

E3. Section "3 Normative References"

The document number for Meta Object Facility (MOF) 2.0 XMI Mapping Specification contains a typo - "OMG Document formal.-5-09-01" should be "OMG Document formal/05-09-01".

E4. Section "7.2.5.3 Partner role descriptions"

The table contains a superfluous hyphen in "person" in one role description "per-son".

E5. Section "7.2.11.3 Process definition"

Contains mis-hyphenation of "example" ("ex-ample").

E6. Figures 7-11, 7-12, 7-13, 7-14 garbled in the PDF

(But I believe this was fixed in the errata during the meeting).

E7. Section "7.2.2 UML package"

The phrase "XML provides an own mechanism ..." should be "XML provides its own mechanism ..."

E8. Section "7.2 UML profile for XML Schema (Informative)"

The phrase "An UML profile ..." occurs 5 times on pages 371, 376 & 378. Should be "a UML profile".

E9. Section "7.2 UML profile for XML Schema (Informative)"

The phrase "... stereotypes, tagged value called properties ...." should be "... stereotypes, tagged values called properties ....".

change as described in the summary

Issue name: "None are defined at the Moment"

Contains the text "At the moment none are defined." Either this section should be removed from the specification, or at the very least the words "At the moment" should be removed.

Delete all empty constraints and assertions chapters from the specification document.

This section contains several sections entitled "Process Flow Diagram", containing the text "At the moment no flow diagram exists". I suggest these sections be removed from the specification, or process diagrams supplied. At the very least, the words "At the moment" should be removed.

Delete all empty Process Flow Diagram chapters from the specification document.

Issue name: "Authorization under discussion"

Contains the text "The topic "Authorization and Network Security" is under discussion and will be documented in a separate specification". This section should be removed from the specification.

Change as described in summary.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.63 Cause: Location step instance project_assignment_step is incorrect. The type Project_information_select given by attribute role_declaring_type_name does not provide the named relationship project_assignment as given by the attribute role_name. Furthermore, an additional Location_step instance is needed in order to select instances of Project_information_select filtered by the existing Type_predicate instance. New Specification Text: Since the specific query is called Project_assignment_query the intended semantics is to select instances of type Project_assignment for the identical named relationship of instances of type Project. From this it follows that Location_step instance project_assignment_step has to be assigned attribute values as follows: * attribute role_declaring_type_name has to be set to Project and * attribute role_name remains project_assignment. Furthermore, Location_step instance project_assignment_step has to be assigned another Location_step instance named project_information_select_step by the named relationship next_query with the following attribute values: * attribute role_declaring_type_name has to be set to Project_assignment and * attribute role_name remains is_applied_to. Finally, the existing instance of Alternative_predicate assigned to Location_step instance project_assignment_step by the named relationship related_object_predicate has to be assigned (i.e. moved) to Location_step instance project_information_select_step by the identical named relationship.

Since the specific query is called Project_assignment_query the intended semantics is to select instances of type Project_assignment for the identical named relationship of instances of type Project. From this it follows that Location_step instance project_assignment_step has to be assigned attribute values as follows:
· attribute role_declaring_type_name has to be set to Project and
· attribute role_name remains project_assignment.
Furthermore, Location_step instance project_assignment_step has to be assigned another Location_step instance named project_information_select_step by the named relationship next_query with the following attribute values:
· attribute role_declaring_type_name has to be set to Project_assignment and
· attribute role_name remains is_applied_to.
Finally, the existing instance of Alternative_predicate assigned to Location_step instance project_assignment_step by the named relationship related_object_predicate has to be assigned (i.e. moved) to Location_step instance project_information_select_step by the identical named relationship.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.6 and Figure 9.16 Cause: Cardinality of aggregation from PLM_reference_feature to PLM_root_object is wrong. Furthermore, the directed relationships from PLM_containment_feature and PLM_reference_feature to PLM_root_object are wrong; both relationships have to point to PLM_object. Additional types defined by the proxy queries conformance point (including PLM_int_feature, PLM_double_feature, etc.) are missing as well. New Specification Text: Figure 9.16: The cardinality of the aggregation from PLM_reference_feature to PLM_root_object has to be 1..* at the directed end-point toward PLM_root_object. Furthermore, the directed relationships from PLM_containment_feature and PLM_reference_feature to PLM_root_object have to point to PLM_object. Finally, the missing types PLM_string_feature, PLM_boolean_feature, PLM_int_feature and PLM_double_feature have to be included.

Resolution:
Figure 9.16: The cardinality of the aggregation from PLM_reference_feature to PLM_root_object has to be 0..* at the directed end-point toward PLM_root_object. Furthermore, the directed relationships from PLM_containment_feature and PLM_reference_feature to PLM_root_object have to point to PLM_object. Finally, the missing types PLM_string_feature, PLM_boolean_feature, PLM_int_feature and PLM_double_feature have to be included.

PLM Services 2.0
mantis/07-03-01 Update
March 29th 2007

Chapter 9.7.49, SpecificQueries.xsd, Chapter 9.8.7

Author:

Guido Adolphi, PROSTEP AG

Subject:

1. Issue 11232 shall be rejected, reason: technically incorrect
2. New Issue:
a. Item_use_query shall obtain status "deprecated" (both in the specification and SpecificQueries.xsd)
b. Assembly_structure_query shall be removed from SpecificQueries.xsd
c. Re-definition of chapter 9.8.7 Item_traversal_query as specified below

New specification Text for Chapter 9.8.7:

The Item_traversal_query traverses from a Design_discipline_item_definition object to the next higher or next lower Design_discipline_item_definition objects in an assembly structure.

Parameters

· uid: UID
· inverse_direction: Boolean[0..1]

Part c accepted as proposed in summary.

because type Axis2_placement_3d is a derived type of Axis_placement
and PLM_container has a composition for type Axis_placement
and so there is no need for the 'axis2_placement_3d' composition.

No Data Available

To reduce complexity of service interfaces the operations

query(query: PLM_query)

and

export_data(PLM_query query, properties: PLM_property[0..*])

should be joined to one single operation

query(query: PLM_query, properties: PLM_property[0..*])

with the semantics of actual 'query' operation if the 'properties' parameter is empty and
with the semantics of the actual 'export_data' operation otherwise.

Merge the two operations into one by deleting the more specialized export_data operation from chapter 9.2.6.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.8.7 and Figure 9.95 Cause: The two instances of type Conditional_query named item_use_query and assembly_structure_query use the same boolean value for their attribute condition. Hence, both instances of type Conditional_query shall be combined into one single Conditional_query instance. Furthermore, the type Assembly_structure_query is undefined in the computational model. Instead Item_instance_query shall be used. New Specification Text: In figure 9.95 the instances of type Conditional_query named item_use_query and assembly_structure_query have to be combined into one single Conditional_query instance named item_traversal_query. The named relationship when_true has to be assigned the existing Item_use_query instance, and the named relationship when_not_true has to be assigned an instance of type Item_instance_query. The instance of type Assembly_structure_query has to be removed.

In figure 9.95 the instances of type Conditional_query named item_use_query and assembly_structure_query have to be combined into one single Conditional_query instance named item_traversal_query. The named relationship when_true has to be assigned the existing Item_use_query instance, and the named relationship when_not_true has to be assigned an instance of type Item_instance_query. The instance of type Assembly_structure_query has to be removed.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.71 and Figure 9.87 Cause: For consistency reasons the Location_step instance work_request_relationship_step has to be renamed into scope_step. New Specification Text: In figure 9.87 the Location_step instance work_request_relationship_step has to be renamed into scope_step.

Resolution:
In figure 9.87 the Location_step instance work_request_relationship_step has to be renamed into scope_step.

Join operations for query 'PLM_properties_descriptors' of an operation with an 'properties' parameter:

get_general_connection_properties_descriptors()
get_message_connection_properties_descriptors()
get_export_data_properties_descriptors()
...

into one operation:

get_operation_properties_descriptors(operation_name: Strring)

to reduce complexity of service interfaces

Delete get_export_data_properties_descriptors() only.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.8.1 and Figure 9.89 Cause: The parameter listing of the General_detail_query is erroneous regarding the parameter uid. The General_detail_query is meant to select details for a set of objects identified by their identifying attribute uid. As figure~9.89 shows, the set of uids will be passed to the Objects_by_uid_query instance equivalent_specific_query_instance. But the General_detail_query provides only a parameter called uid with cardinality 1..1 while the specialization General_detail_query in figure~9.89 correctly introduces a parameter named uids with cardinality 1..*. New Specification Text: The parameter list of General_detail_query within the description text has to correct the declaration of parameter uid: UID into uids: UID[1..*].

The parameter list of General_detail_query within the description text has to correct the declaration of parameter uid: UID into uids: UID[1..*].

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.40 and Figure 9.56 Cause: The Location_path instance assigned to the named relationship first_query of the Concatenated_query instance equivalent_query has no instance-name. The same holds for the first Location_step instance assigned to the named relationship first_step. New Specification Text: In figure 9.56 the Location_path instance assigned to the named relationship first_query of the Concatenated_query instance equivalent_query has to be named event_reference_path, and the Location_step instance assigned to the named relationship first_step of that Location_path instance has to be named event_reference_step.

In figure 9.56 the Location_path instance assigned to the named relationship first_query of the Concatenated_query instance equivalent_query has to be named event_reference_path, and the Location_step instance assigned to the named relationship first_step of that Location_path instance has to be named event_reference_step.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.30 and Figure 9.46 Cause: For consistency reasons the Location_step instance design_discipline_definition_step has to be renamed into design_discipline_item_definition_step according to the identical element of the informational model. New Specification Text: In figure 9.46 the Location_step instance design_discipline_definition_step has to be renamed into design_discipline_item_definition_step.

In figure 9.46 the Location_step instance design_discipline_definition_step has to be renamed into design_discipline_item_definition_step.

Check the operations without a generic property list parameter if it make sense to add such a parameter.
to allow more system specific functionality via the PLM Services interfaces

For instance in interface PLM_general_connection
delete(uids : UID[1..*], properties: PLM_property[0..*])
the parameter properties can control the recurrsive removal of whole structures.

or get_download_URL(uid: UID, , properties: PLM_property[0..*])
the parameter properties can control the protocol of the URL (ftp, http, ...), of the result.

If the PLM Services interfaces are used by more specific applications the product life cycle,
for instance project management or engineering change management, they can specify
conformant property values of the generic and optional properties parameters for their domain

No Data Available

To reduce complexity of service interfaces the operations

write(container: PLM_core_container, fill_result_list: boolean)

and

import_data(container: PLM_core_container, properties: PLM_property[0..*])

should be joined to one single operation

write(container: PLM_core_container, fill_result_list: boolean, properties: PLM_property[0..*])

with the semantics of actual 'write' operation if the 'properties' parameter is empty and
with the semantics of the actual 'import_data' operation otherwise.

Merge the two operations into one by deleting the more specialized import_data operation from chapter 9.2.6.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.4 and Figures 9.13 and 9.14 Cause: Some cardinalities are wrong in the definition of Location_path and Location_step, and compositions are missing in the definition of Relationship_predicate. New Specification Text: Figure 9.13: The reflexive composition +next_step of Location_step has to be assigned cardinality 0..* at the directed end-point toward Location_step. Figure 9.14: The compositions of related_object_predicate and relating_object_predicate of Relationship_predicate have to be added.

Figure 9.13: The reflexive composition +next_step of Location_step has to be assigned cardinality 0..* at the directed end-point toward Location_step. Figure 9.14: The compositions of related_object_predicate and relating_object_predicate of Relationship_predicate have to be added.

PLM Services 2.0, mantis/07-03-01 Update, Chapters 9.3, 9.4, 9.7, 9.8 and Figures 9.12, 9.13, all figures from chapters 9.7 and 9.8 Cause: Throughout the computational model compositions are either missing or denoted as aggregations. New Specification Text: Figure 9.12: Composition from Recursive_query to PLM_query with role-name query is missing. Figure 9.13: All aggregations have to be denoted as compositions. All figures from chapter 9.7: All aggregations have to be denoted as compositions. All figures from chapter 9.8: All aggregations have to be denoted as compositions.

No Data Available

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.28 and Figure 9.44 Cause: In Location_step instance configuration_step the type Configuration_item_select given by the attribute role_declaring_type_name does not exist in the informational model. Instead the attribute role_declaring_type_name has to be set to Configured_item_select. New Specification Text: In figure 9.44 attribute role_declaring_type_name of Location_step instance configuration_step has to be set to Configured_item_select

In figure 9.44 attribute role_declaring_type_name of Location_step instance configuration_step has to be set to Configured_item_select

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.19 and Figure 9.35 Cause: Type Document_representation has no named relationship file. Digital_document--a derivation of Document_representation--provides the named relationship file. New Specification Text: In figure 9.35 Location_step instance associated_file_step has to be assigned attribute role_declaring_type_name to value Digital_document.

In figure 9.35 Location_step instance associated_file_step has to be assigned attribute role_declaring_type_name to value Digital_document.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.62 and Figure 9.78 Cause: For consistency reasons the Location_step instance product_structure_location_step has to be renamed into product_structure_relationship_step according to the identical element of the informational model. New Specification Text: In figure 9.78 the Location_step instance product_structure_location_step has to be renamed into product_structure_relationship_step.

In figure 9.78 the Location_step instance product_structure_location_step has to be renamed into product_structure_relationship_step.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.42 and Figure 9.63 Cause: The type Product_information as declared in the Location_step instance item_instance_step2 by attribute role_declaring_type_name does not exist in the informational model. Instead attribute role_declaring_type_name has to be set to Product_identification. New Specification Text: In figure 9.63 the attribute role_declaring_type_name of Location_step instance item_instance_step2 has to be set to Product_identification.

In figure 9.63 the attribute role_declaring_type_name of Location_step instance item_instance_step2 has to be set to Product_identification.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.4.10 Cause: Some editorial and spelling mistakes. The attribute Maximum_number determines the maximum number of objects selected from the sorted initial node-set of a location step. However, Start_index+Maximum_number selects one more object as intended. Start_index+Maximum_number-1 is appropriate for the semantics of Sort_predicate. New Specification Text: The Sort_predicate arranges objects of the initial node-set of a Location_step by the attribute specified by the attribute attribute_name of the Sort_predicate. The type of the attribute specified by attribute_name has to be a type for which a greater-than and less-than relation is defined. The default sort order is ascending order. If the attribute Descending_order of the Sort_predicate is set to true the selected objects are sorted in descending order. If the attribute Start_index is set all objects of the sorted node-set before the start index are filtered out. The default start index is 0. If the attribute Maximum_number is set objects before and after the closed range [Start_index, Start_index+Maximum_number-1] are filtered out.

Correct, change according to summary.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.21 and Figure 9.37 Cause: The location step property_value_association_step is unable to select instances of Property_value_representation since inverse is implicitly set to false. Furthermore, location step property_value_representation_step is unable to select instances of Property_value since inverse is implicitly set to false. Finally, location step global_unit_step cannot select instances of type Unit since the named relationship global_unit is defined in Property_value_representation, but the result-set of the preceding location step does not contain any Property_value_representation at all. For consistency reasons the names of the mentioned location steps shall be adjusted. New Specification Text: The following is a literal description of the changes to be made in figure~9.37. The location steps property_value_association_step and property_value_representation_step must have the attribute inverse set to true in order to select instances of Property_value_representation and Property_value properly. Furthermore, the location step global_unit_step has to be the next step of location step property_value_association_step to select Unit instances by the named relationship Property_value_representation.global_unit. For consistency reasons location step property_value_association_step has to be renamed into inverse_property_value_representation_step (since the inverse location step selects instances of type Property_value_representation) and property_value_representation_step has to be renamed into inverse_property_value_step (since the inverse location step selects instances of type Property_value).

For consistency reasons the names of the mentioned location steps shall be adjusted.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.61 and Figure 9.77 Cause: Composition between Location_path and Location_step instances is missing. No role-names given for predicates. New Specification Text: In figure 9.77 a composition has to be included between the instances of Location_path and Location_step. The role-name of this composition has to be +first_step. Furthermore, all compositions to predicates have to be assigned the role-name +related_object_predicate.

In Figure 9.77 a composition has to be included between the instances of Location_path and Location_step. The role-name of this composition has to be +first_step. Furthermore, all compositions to predicates have to be assigned the role-name +related_object_predicate.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.49 and Figure 9.65 Cause: Item_use_query does not provide an attribute called maximum_resursion_number---this is only provided by the Recursive_query. Furthermore, the Location_step instance item_instance_step selects all Item_instance instances no matter if they are related (i.e. used) by another Item_instance instance via Item_definition_instance_relationship elements or not. In order to constrain the set of selected Item_instance instances with respect to the semantics intended by the Item_use_query, an additional Relationship_predicate has to be added to Location_step instance item_instance_step. New Specification Text: In figure 9.65 the Location_step instance item_instance_step has to be added a Relationship_predicate to the named relationship related_object_predicate of the Location_step. The predicate instance has to be named inverse_item_definition_instance_relationship_predicate with its attributes initialized as follows: * attribute inverse is set to true, * attribute role_name is set to related and * attribute role_declaring_type_name is set to Item_definition_instance_relationship. Finally, for consistency reasons, the Location_step instance inverse_assembly_component_relationship_step has to be renamed to inverse_item_definition_instance_relationship_step.

In Figure 9.65 the Location_step instance item_instance_step has to be added a Relationship_predicate to the named relationship related_object_predicate of the Location_step. The predicate instance has to be named inverse_item_definition_instance_relationship_predicate with its attributes initialized as follows:
· attribute inverse is set to true,
· attribute role_name is set to related and
· attribute role_declaring_type_name is set to Item_definition_instance_relationship
Finally, for consistency reasons, the Location_step instance inverse_assembly_component_relationship_step has to be renamed to inverse_item_definition_instance_relationship_step

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.45 and Figure 9.61 Cause: The Conditional_query has no relationships to Location_step but to PLM_query. The Location_path instances are missing as glue between the instances of Conditional_query and Location_step. Furthermore, Location_step instance inverse_item_classification_hierarchy_step wants to select elements by the no named relationship related (denoted by role_name="related") from Specific_item_classification_hierarchy elements. However, Specific_item_classification_hierarchy only provides the named relationship sub_classification. New Specification Text: In figure 9.61 two Location_path instances have to be included each referencing one of the existing Location_step instances. The Conditional_query instance equivalent_query_instance has to refer to the new Location_path instances instead. In Location_step instance inverse_item_classification_hierarchy_step the attribute role_name has to be set sub_classification.

In figure 9.61 two Location_path instances have to be included each referencing one of the existing Location_step instances. The Conditional_query instance equivalent_query_instance has to refer to the new Location_path instances instead. In Location_step instance inverse_item_classification_hierarchy_step the attribute role_name has to be set sub_classification.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.42 and Figure 9.58 Cause: All Location_step instances are erroneous. New Specification Text: In the following each Location_step instance of figure 9.58 is described with the required corrections: * file_creation_step: The attribute role_name has to be set to creation. * file_content_step: The attribute role_name has to be set to content. * file_type_location_step: Instance-name has to be set to file_type_step, and attribute role_name has to be set to document_file_type. * file_format_step: The attribute role_name has to be set to file_format. * file_location_step: The attribute role_name has to be set to external_id_and_location. * file_size_step: The attribute role_name has to be set to size.

In the following each Location_step instance of figure 9.58 is described with the required corrections:
· file_creation_step: The attribute role_name has to be set to creation.
· file_content_step: The attribute role_name has to be set to content.
· file_type_location_step: Instance-name has to be set to file_type_step, and attribute role_name has to be set to document_file_type.
· file_format_step: The attribute role_name has to be set to file_format.
· file_location_step: The attribute role_name has to be set to external_id_and_location.
· file_size_step: The attribute role_name has to be set to size.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.32 and Figure 9.48 Cause: The Conditional_query has no relationships to Location_step but to PLM_query. The Location_path instances are missing as glue between the instances of Conditional_query and Location_step. Furthermore, Location_step instance inverse_document_classification_hierarchy_step wants to select elements by the no named relationship related (denoted by role_name="related") from Specific_document_classification_hierarchy elements. However, Specific_document_classification_hierarchy only provides the named relationship sub_classification. New Specification Text: In figure 9.48 two Location_path instances have to be included each referencing one of the existing Location_step instances. The Conditional_query instance equivalent_query_instance has to refer to the new Location_path instances instead. In Location_step instance inverse_document_classification_hierarchy_step the attribute role_name has to be set sub_classification.

In figure 9.48 two Location_path instances have to be included each referencing one of the existing Location_step instances. The Conditional_query instance equivalent_query_instance has to refer to the new Location_path instances instead. In Location_step instance inverse_document_classification_hierarchy_step the attribute role_name has to be set sub_classification.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.37 and Figure 9.53 Cause: Base class of specific query Document_representation_query is PLM_query rather than Specific_query since Document_representation_query is an element of the specific queries conformance point. New Specification Text: Changes to figure 9.53: base class of Document_representation_query has to be Specific_query.

Correct reference is to Document_version_query in Chapter 9.7.37:Base class of Document_version_query has to be Specific_query. Update Figure 9.53

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.4.7 Cause: The specification of the Relationship_predicate is imprecise, need some bug fixes and additions: * All partial constraints have to be fulfilled. * A new constraint for the named relationship relating_object_predicate has to be added. New Specification Text: An object fulfills a Relationship_predicate constraint if it fulfills all of the following partial constraints: * The object fulfills all predicate instances referenced by the named relationship relating_object_predicate of the Relationship_predicate. * The object is related with another object that fulfills all predicate instances referenced by the named relationship related_object_predicate of the Relationship_predicate. * If the value of the attribute inverse of the Relationship_predicate is set to false, and if the attribute role_name is set, the role name of the other object in the relationship must be equal to the value of the attribute role_name of the Relationship_predicate. * If the value of the attribute inverse of the Relationship_predicate is set to true, and if the attribute role_name is set, the role name of this object in the relationship must be equal to the value of the attribute role_name of the Relationship_predicate. * If the attribute role_declaring_type_name is set, the relationship must be defined in a type which name is equal to the value of the attribute role_declaring_type_name.

1. ALL constraints must be fullfilled.
2. The attribute 'predicate' is now named 'related_object_predicate'
3. A new constraint for the attribute 'relating_object_predicate' has to be added.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.39 Cause: Description is incomplete. Beside Effectivity elements instances of Duration, Organization and Event_or_date_select are selected. New Specification Text: The Effectivity_query selects Effectivity objects with additional related instances of Duration, Organization and Event_or_date_select.

The Effectivity_query selects Effectivity objects with additional related instances of Duration, Organization and Event_or_date_select.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.38 and Figure 9.54 Cause: Location step instance effective_element_step is defined incompletely. New Specification Text: Location step instance effective_element_step in figure 9.54 needs attribute role_declaring_type_name set to Effectivity_assignment and attribute role_name set to effective_element.

Location step instance effective_element_step in figure 9.54 needs attribute role_declaring_type_name set to Effectivity_assignment and attribute role_name set to effective_element.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.31 and Figure 9.47 Cause: Base class of specific query Document_classification_query is PLM_query rather than Specific_query since Document_classification_query is an element of the specific queries conformance point. New Specification Text: Changes to figure 9.47: base class of Document_classification_query has to be Specific_query.

Correct, change as summarized.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.30 and Figure 9.46 Cause: Base class of specific query Design_discipline_item_definition_query is PLM_query rather than Specific_query since Design_discipline_item_definition_query is an element of the specific queries conformance point. New Specification Text: Changes to figure 9.46: base class of Design_discipline_item_definition_query has to be Specific_query.

Change in Figure 9.46: base class of Design_discipline_item_definition_query has to be Specific_query. See solution to issue 11227 for the finally updated figure.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.35 and Figure 9.51 Cause: Base class of specific query Document_representation_query is PLM_query rather than Specific_query since Document_representation_query is an element of the specific queries conformance point. New Specification Text: Changes to figure 9.51: base class of Document_representation_query has to be Specific_query.

Changes to figure 9.51: base class of Document_representation_query has to be Specific_query.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.34 and Figure 9.50 Cause: Base class of specific query Document_query is PLM_query rather than Specific_query since Document_query is an element of the specific queries conformance point. New Specification Text: Changes to figure 9.50: base class of Document_query has to be Specific_query.

changes to figure 9.50: base class of Document_query has to be Specific_query.

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.24 Cause: The chapter caption includes a blank character. New Specification Text: New chapter caption has to be "Associated_project_query".

Delete extra characters. New chapter caption has to be "Associated_project_query".

PLM Services 2.0, mantis/07-03-01 Update, Chapter 9.7.6 and Figure 9.22 Cause: The Location_step instance resolved:request_step is misspelled. New Specification Text: The location step instance has to be renamed to resolved_request_step.

Correct as described in summary.

In chapter 8.12.11 (Associated_property_query), as well as Chapter 8.12.34 (Simple_property_query), the attribute unit_component of value_with_unit should be retrieved automatically (although it is an optional attribute), since it makes more sense than to introduce a new Query to retrieve it. The same applies to property_value_representation.global_unit in Associated_property_query.

No Data Available

Add missing query Project_assignment_query in order to allow searching for objects assigned to a given project object, or to allow searching for the project objects that are assigned to a given object. Proposed solution: <xs:complexType name="Project_assignment_query"> <xs:complexContent> <xs:extension base="Query_with_relating_type_predicate "> <xs:sequence> <xs:element name="Role" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available

The description of use of type PLM_container in section 8.6 of the computational model
should be more precise.

No Data Available

One can concatenate Queries via the next_query Relationship
to a bigger batch job.
But the concatenation implies, that the second query uses
the result of the first query as its start node set.

There should be the possibility to define a batch job of independent queries.
For instance:
<xs:complexType name="Batch_query">
<xs:complexContent>
<xs:extension base="Query">
<xs:sequence>
<xs:element name="Query" type="Query" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
All element queries of the Batch_query will de evaluated independly and the partial results
will be joined and returnd as one single result.

No Data Available

Add missing query Work_request_classification_query in order to allow searching for specific general_classification objects that are associated to a specific Work_request object. Proposed solution: <xs:complexType name="Work_request_classification_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Role" type="xs:string" minOccurs="0"/> <xs:element name="Id" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available

Add missing Work_request_query in order to allow searching for specific work_request objects. Proposed solution: <xs:complexType name="Work_request_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Id" type="xs:string" minOccurs="0"/> <xs:element name="Request_type" type="xs:string" minOccurs="0"/> <xs:element name="Status" type="xs:string" minOccurs="0"/> <xs:element name="Version_id" type="xs:string" minOccurs="0"/> <xs:element name="Classification_role" type="xs:string" minOccurs="0"/> <xs:element name="Classification_id" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available

We need a special exception type for unsupported operations,
for instance in an ReadOnly PLMConnector all modifying
operations (PLMConnection.write, PLMConnection.delete, ..)
have to throw an Unsupported_operation_exception.

No Data Available

In chapter 8.12.10 (Associated_organization_query), chapter 8.12.31 (Organization_query), as well as in the newly introduced Associated_date_organization_query, Associated_person_organization_query and Organization_relationship_query the attributes postal_address, delivery_address and visitor_address of organization should be retrieved automatically (although they are optional attribute), since it makes more sense than to introduce a new Query to retrieve them. The same applies to preferred_business_address of person in Associated_date_organization_query and Associated_person_organization_query.

No Data Available

Add missing query Person_in_organization_relationship_query in order to allow searching for specific Person_in_organization objects related yo an Person_in_organization_relationship object starting at an given Person_in_organization object. Proposed solution: <xs:complexType name="Person_in_organization_relationship_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Relation_type" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available

Add missing query Work_request_scope_query in order to allow searching for specific elements of the scope of an given Work_request object. Proposed solution: <xs:complexType name="Work_request_scope_query"> <xs:complexContent> <xs:extension base="Query"/> </xs:complexContent> </xs:complexType>

No Data Available

Add missing Associated_date_organization_query in order to allow searching for organizational objects (date_time comined with person, organization, person_in_organization) that are assigned to a given object, or to allow searching for objects that are referenced by a given organizational object (date, person, organization, person_in_organization). Proposed solution: <xs:complexType name="Associated_date_organization_query"> <xs:complexContent> <xs:extension base="Query_with_relating_type_predicate"> <xs:sequence> <xs:element name="Role" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available

Add missing Associated_activity_query in order to allow searching for activity objects that are associated to a specific work_request object. Proposed solution: <xs:complexType name="Associated_activity_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Activity_type" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available

Add complex type Person_in_organization_relationship according to STEP AP214 IS version. Proposed solution: <xs:complexType name="Person_in_organization_relationship"> <xs:complexContent> <xs:extension base="PLM_object"> <xs:sequence> <xs:element name="Related" type="xs:IDREF"/> <xs:element name="Relation_type" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available

The predicates of a location step filter the related objects only.
To define the semantic of the attribute "relating_type_names"
of the associatedXyzQueries we need the possibility to filter
the relating objects (the start nodes of a location step) too.

This could be done by an additional feature for the types
"Location_step" and "Relationship_predicate" of type "Predicate"
named "relating_object_predicate".
For consistency the existing feature "Predicate" of these types
should be renamed in "related_object_predicate"

No Data Available

For a better matching of name and semantic
the Item_relationship_query should be renamed to Item_version_relationship_query.

No Data Available

For better selection possibilities
the Alias_identification_query should be extended with optional Attributes
Alias_id, Alias_version_id and Alias_scope.

No Data Available

Rename Approval_query to Associated_approval_query
For the consistency of query names in the computational model
the Approval_query should be renamed to Associated_approval_query.

No Data Available

For each Type used as Parameters, Return values or Exceptions in the WSDL
one Root Elements should be defined in the XML Schemas used by the WSDL.
No other type should be used in a root element definition.

No Data Available

Add missing Organization_relationship_query in order to allow searching for specific organization objects related by an organization_relationship object starting at an given organization object. Proposed solution: <xs:complexType name="Organization_relationship_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Relation_type" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available

Add missing Associated_person_organization_query in order to allow searching for organizational objects (person, organization, person_in_organization) that are assigned to a given object, or to allow searching for objects that are referenced by a given organizational object (person, organization, person_in_organization). Proposed solution: <xs:complexType name="Associated_person_organization_query"> <xs:complexContent> <xs:extension base="Query_with_relating_type_predicate"> <xs:sequence> <xs:element name="Role" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available

Add missing query Activity_relationship_query in order to allow searching for specific activity objects related by an Activity_relationship object starting at an given activity object. Proposed solution: <xs:complexType name="Activity_relationship_query"> <xs:complexContent> <xs:extension base="Query"> <xs:sequence> <xs:element name="Relation_type" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

No Data Available