-A general comment - the relative path is built in the engineering tool - which only have the AC NodeId or the well known FXRoot item in many cases - the nodeid of a folder is not required for the descriptor - so it can not be a starting point from an engineering tool point of view.

6.11.2 ConnectionEndpointConfigurationType - FunctionalEntityNode
Currently description says the path is relative to FxRoot. To shorten the path, it can be made relative to the AC. The containing AC is known thanks to the ToConnectionEndpointConfiguration reference.

Paul - The ToConnectionEndpointConfiguration is a non-hierarchical reference, which is not easy to follow (translate Browse paths does not process it, the FLCRoot is a well known object and can be hardcoded in the path in the engineering tool

6.12.2 ConnectionEndpointDefinitionType - Node
Root not specified. Relative to FE?

paul - the mistake here is that this should be a PortableNodeid not an identifier - this should be fixed (it is where the Nodeid is stored once parameter is processed)

6.11.2 ConnectionEndpointConfigurationType - ExpectedVerificationVariables, ControlGroups, ConfigurationData
Currently description says the path is relative to FunctionalEntityNode. But it can be relative to the corresponding folder within the FE.

paul - for verification we have said it can be anything in the FE - so this is correct, , for controlgroup - it can be control groups in sub functionalentities - so again it is correct, same a control groups - can be sub functionalentities

6.13.2 ConnectionEndpointParameterType definition - InputVariableIds, InputGroupId, OutputVariableIds, OutputGroupId
For groups, the root of the path has to be FE (to account for the fact that the top level OutputData and InputData could be specified). But for individual variables, start of the path can be the corresponding Input or Output folder, not FE as it is at the moment.

paul - again nested functionalentities require the FE, instead of the folder.

6.16.2 AssetVerificationType definition - AssetToVerify
Can be relative to Assets folder in AC.

paul - agreed that this could be, but the assetfolder would have to first be found - since that nodeid is not know in the descriptor (by the engineering tool) - at least I don;t think it is in the descriptor- it would reequire a two step processing - I think it is easier to just start at the AC - which is already being provided.

6.16.2 AssetVerificationType definition - ExpectedAdditionalVerificationVariables
Root not specified. Relative to what?

paul - Agreed this one is missing the starting definition, but I'm not sure we have the type correct since the variable has to be defined in the Asset (if you look at the method) - I think a relative path is incorrect this should be protableNodeis, or PortableBrowsename, nothing else.

In call determined that there might be a manner to add a generic path to CM so the configuration in the configuration set might not need the additional path items. This possible option will be illustrated to all via a PPT, before this issue is assigned.

Discuss in call - that this could be handled in vendor specific implementation (think string pools), issue can be acknowledge and left for next release if it show to be an issue - otherwise can be close in next release.

Attached PPT that include all on the initial discussion on the issue

What is remaining at this point is a possible optimization - waiting for implementations to determine if anything is actually needed

All Agree nothing more to do

agreed in prototyping that nothing more is needed