All relationships in the PIM which are defined in different types
but which are (potentially) used together in queries,
(f.i. Associated_document_query for associated documents
independend of the association source type)
should have common base interfaces in the PIM which define this relationships.

These interfaces and relationships have no impact for the web service PSM
but eventually for future PSM.

Interface Alias_select
Compositions:
Alias_identification Implemtented By:
Organization
Complex_product
Classification_attribute
Item
Document_type_property
Product_class
Document_version
Specification_category
Document
Specification
Item_version
Classification_system
Item_instance
Document_representation
Property
General_classification
Design_discipline_item_definition
Physical_instance
Approval_status

Interface Configured_item_select
Compositions:
Configuration
Implemented By:
Process_operation_occurrence
Product_function
Product_component
Alternative_solution
Process_plan
Item_instance

Interface Documented_element_select
Compositions:
Document_assignment
Implemented By:
Shape_element_relationship
Process_operation_occurrence
Work_order
Product_identification
Organization
Physical_instance_test_result
Item_definition_instance_relationship
Complex_product
Classification_attribute
Item
Product_class
Item_definition_relationship
Specification_category
Change
Specific_item_classification
Material
Specification
Item_version
Activity_element
Project
Classification_system
Process_plan
Activity_method
Approval
Item_instance
Descriptive_specification
Property
Product_structure_relationship
Shape_element
General_classification
Design_discipline_item_definition
Item_instance_relationship
Physical_instance
Work_request
Item_shape
Design_constraint
Physical_assembly_relationship
Activity
Class_structure_relationship
Person

Interface person_organization_select
Compositions:
Date_and_person_organization
Person_organization_assignment
Implemented By:
Person_in_organization
Organization

Interface instance_definition_select
Compositions:
Item_instance
Implemented By:
Product_identification
Design_discipline_item_definition

Interface Shape_information_select
Compositions:
Shape_description_association
Implemented By:
Shape_element_relationship
Shape_element
Item_shape

Interface Specification_operand_select
Composition:
Specification_inclusion
Implemented By:
Specification
Specification_expression

Interface Change_relationship_select
Compositions:
Change
Implemented By:
Process_operation_occurrence_relationship
Process_plan_relationship
Shape_element
Replaced_definition_relationship
Item_version_relationship

The following Compositions should be added to existing
interfaces in the PIM:

Interface Process_property_select
Compositions:
Simple_property_value

Interface Item_property_select
Compositions:
Simple_property_value

Interface Geometric_or_external_model_select
Compositions:
Geometric_model_relationship

The "associated" prefix for some querie names seems to be used arbitrary. "Associated_document_query" asks for associated documents but "Item_classification_query" asks for associated item_classifications. Clear guidelines shall be given for using that prefix.

The Computational Model defines many different Types:
Service Interfaces
Exception Types
Generic Query Types
PDTnet Query Types
Message Types
and other.

This Types should be separated into
different subpackages of the Computational Model PIM
and different schemas in the Computational Model WebService PSM.

The result of the concatenation of queries
is defined as the union of the result of the
single queries.

Some use cases needs another semantic of concatenated queries.
F.i. for the Start node identification use case
the set of Items selected by an Item_query
have to be filtered by an (optional)
following Item_version_query.
In this case the ItemQuery doesn't contribute directly to the
result of the whole concatenated query
but is only an intermediate step to define the start nodes
of the following Item_version_query.

To switch the semamtics of concatenation between

A) union of single result
B) intermediate step without contribution to the result
but with contribution to the start nodes of the next queries
a flag should be added to the class Query called "Intermediate".

Add complex type Section_context according to the requirements described in the VDA Recommendations for the Exchange of digital Engineering Change Requests (ECR). Proposed solution: <xs:complexType name="Section_context"> <xs:complexContent> <xs:sequence> <xs:element name="Msg_type" type="xs:string"/> <xs:element name="Dunsnr" type="xs:string"/> <xs:element name="Interactionid" type="xs:string"/> <xs:element name="Newinteractionid" type="xs:string" minOccurs="0"/> <xs:element name="Interactionscenarioname" type="xs:string"/> <xs:element name="Messagename" type="xs:string"/> <xs:element name="Sequenceno" type="xs:integer"/> <xs:element name="Iscomplete" type="xs:boolean"/> </xs:sequence> </xs:complexContent> </xs:complexType>

There is a discrepancy between the base standard ISO 10303-214 and the OMG PLM Services 1.0 with respect to the multiplicity of relations. While in AP214 of the template “SET [0:?]” is used, in the PLM Services, especially in the XML platform specific model the template “optional SET [1:?]” is used. Although this mapping may be semantically equal, a problem arises with respect to the automatic translation between ISO 10303-21 files and PLM XML files/streams. Proposed solution: consider revising the mapping of cardinalities of type “optional SET [1:?]” in the PLM (XML) Services into “SET [0:?]”.

The WSDL and the XML Schema should be extended by xsd:appinfo's with informations about the allowed types for the xs:IDREF(S) which are modelled as interfaces in the PIM.

The semantics of the specified Alternative_solution_query is to find
associated Alternative_solutions for Complex_products.

So its name should be changed to Associated_alternative_solution_query.