UA Part 4: Services - Annex B (informative)ContentFilter and Query examples

Annex B (informative)ContentFilter and Query examples

These examples provide fairly simple ContentFilters. Filter similar to these examples may be used in processing events.

The following conventions apply to these examples with regard to how Attribute operands are used (for a definition of this operand see 7.7.4):

AttributeOperand: Refers to a Node, an Attribute of a Node or the Value Attribute of a Property associated with a Node. In the examples, the character names of NodeIds are used instead of an actual nodeId, this also applies to Attribute Ids.
The string representation of relative paths is used instead of the actual structure.
The NamespaceIndex used in all examples is 12 (it could just as easily have been 4 or 23 or any value). For more information about NamespaceIndex, see OPC 10000-3. The use of the NamespaceIndex illustrates that the information model being used in the examples is not a model defined by this document, but one created for the examples.

B.1.2 Example 1

For example the logic describe by ‘(((AType.A = 5) or InList(BType.B, 3,5,7)) and BaseObjectType.displayName LIKE “Main%”)’ would result in a logic tree as shown in Figure B.1 and a ContentFilter as shown in Table B.1. For this example to return anything AType and BType both shall be subtypes of BaseObjectType, or the resulting “And” operation would always be false.

Figure B.1 – Filter logic tree example

Table B.1 describes the elements, operators and operands used in the example.

Table B.1 – ContentFilter example

Element[]	Operator	Operand[0]	Operand[1]	Operand[2]	Operand[3]
0	And	ElementOperand = 1	Element Operand = 4
1	Or	ElementOperand = 2	Element Operand = 3
2	Equals	AttributeOperand = NodeId: AType, BrowsePath: “.12:A”, Attribute:value	LiteralOperand = ‘5’
3	InList	AttributeOperand = NodeId: BType, BrowsePath: “.12:B”, Attribute:value	LiteralOperand = ‘3’	LiteralOperand = ‘5’	LiteralOperand = ‘7’
4	Like	AttributeOperand = NodeId: BaseObjectType, BrowsePath: “.”, Attribute: displayName	LiteralOperand = “Main%”

B.1.3 Example 2

As another example a filter to select all SystemEvents (including derived types) that are contained in the Area1 View or the Area2 View would result in a logic tree as shown in Figure B.2 and a ContentFilter as shown in Table B.2.

Figure B.2 – Filter logic tree example

Table B.2 describes the elements, operators and operands used in the example.

Table B.2 – ContentFilter example

Element[]	Operator	Operand[0]	Operand[1]
0	And	ElementOperand = 1	ElementOperand = 4
1	Or	ElementOperand = 2	ElementOperand = 3
2	InView	AttributeOperand = NodeId: Area1, BrowsePath: ".", Attribute: NodeId
3	InView	AttributeOperand = NodeId: Area2, BrowsePath: ".", Attribute: NodeId
4	OfType	AttributeOperand = NodeId: SystemEventType, BrowsePath: ".", Attribute: NodeId”

B.2 Query Service Set

B.2.1 Overview

This deprecated Service Set is used to issue a Query to a Server. OPC UA Query is generic in that it provides an underlying storage mechanism independent Query capability that can be used to access a wide variety of OPC UA data stores and information management systems. OPC UA Query permits a Client to access data maintained by a Server without any knowledge of the logical schema used for internal storage of the data. Knowledge of the AddressSpace is sufficient.

An OPC UA Application is expected to use the OPC UA Query Services as part of an initialization process or an occasional information synchronization step. For example, OPC UA Query would be used for bulk data access of a persistent store to initialise an analysis application with the current state of a system configuration. A Query may also be used to initialise or populate data for a report.

A Query defines what instances of one or more TypeDefinitionNodes in the AddressSpace should supply a set of Attributes. Results returned by a Server are in the form of an array of QueryDataSets. The selected Attribute values in each QueryDataSet come from the definition of the selected TypeDefinitionNodes or related TypeDefinitionNodes and appear in results in the same order as the Attributes that were passed into the Query. Query also supports Node filtering on the basis of Attribute values, as well as relationships between TypeDefinitionNodes.

B.2.2 Querying Views

A View is a subset of the AddressSpace available in the Server. See OPC 10000-5 for a description of the organization of Views in the AddressSpace.

For any existing View, a Query may be used to return a subset of data from the View. When an application issues a Query against a View, only data defined by the View is returned. Data not included in the View but included in the original AddressSpace is not returned.

The Query Services supports access to current and historical data. The Service supports a Client querying a past version of the AddressSpace. Clients may specify a ViewVersion or a Timestamp in a Query to access past versions of the AddressSpace. OPC UA Query is complementary to Historical Access in that the former is used to Query an AddressSpace that existed at a time and the latter is used to Query for the value of Attributes over time. In this way, a Query can be used to retrieve a portion of a past AddressSpace so that Attribute value history may be accessed using Historical Access even if the Node is no longer in the current AddressSpace.

Servers that support Query are expected to be able to access the AddressSpace that is associated with the local Server and any Views that are available on the local Server. If a View or the AddressSpace also references a remote Server, query may be able to access the AddressSpace of the remote Server, but it is not required. If a Server does access a remote Server the access is accomplished using the user identity of the Client as described in 5.6.1.

B.2.3 QueryFirst

This Service is used to issue a Query request to the Server. The complexity of the Query can range from very simple to highly sophisticated. The Query can simply request data from instances of a TypeDefinitionNode or TypeDefinitionNode subject to restrictions specified by the filter. On the other hand, the Query can request data from instances of related Node types by specifying a RelativePath from an originating TypeDefinitionNode. In the filter, a separate set of paths can be constructed for limiting the instances that supply data. A filtering path can include multiple RelatedTo operators to define a multi-hop path between source instances and target instances. For example, one could filter on students that attend a particular school, but return information about students and their families. In this case, the student school relationship is traversed for filtering, but the student family relationship is traversed to select data. For a complete description of ContentFilter see 7.7, also see Clause B.1 for simple examples and Clause B.2 for more complex examples of content filter and queries.

The Client provides an array of NodeTypeDescription which specify the NodeId of a TypeDefinitionNode and selects what Attributes are to be returned in the response. A Client can also provide a set of RelativePaths through the type system starting from an originating TypeDefinitionNode. Using these paths, the Client selects a set of Attributes from Nodes that are related to instances of the originating TypeDefinitionNode. Additionally, the Client can request the Server return instances of subtypes of TypeDefinitionNodes. If a selected Attribute does not exist in a TypeDefinitionNode but does exist in a subtype, it is assumed to have a null value in the TypeDefinitionNode in question. Therefore, this does not constitute an error condition and a null value is returned for the Attribute.

The Client can use the filter parameter to limit the result set by restricting Attributes and Properties to certain values. Another way the Client can use a filter to limit the result set is by specifying how instances should be related, using RelatedTo operators. In this case, if an instance at the top of the RelatedTo path cannot be followed to the bottom of the path via specified hops, no QueryDataSets are returned for the starting instance or any of the intermediate instances.

When querying for related instances in the RelativePath, the Client can optionally ask for References. A Reference is requested via a RelativePath that only includes a ReferenceType. If all References are desired than the root ReferenceType is listed. These References are returned as part of the QueryDataSets.

Query Services allow a special handling of the targetName field in the RelativePath. In several Query use cases a type NodeId is necessary in the path instead of a QualifiedName. Therefore the Client is allowed to specify a NodeId in the QualifiedName. This is done by setting the namespaceIndex of the targetName to zero and the name part of the targetName to the XML representation of the NodeId. The XML representation is defined in OPC 10000-6. When matching instances are returned as the target node, the target node should be an instance of the specified type or subtype of the specified type.

Table B.3 defines the request parameters and Table B.4 the response parameters for the QueryFirst Service.

Table B.3 – QueryFirst Request Parameters

Name	Type	Description
Request
requestHeader	RequestHeader	Common request parameters (see 7.32 for RequestHeader definition).
View	ViewDescription	Specifies a View and temporal context to a Server (see 7.44 for ViewDescription definition).
nodeTypes []	NodeTypeDescription	This is the Node type description. This structure is defined in-line with the following indented items.
typeDefinitionNode	ExpandedNodeId	NodeId of the originating TypeDefinitionNode of the instances for which data is to be returned.
includeSubTypes	Boolean	A flag that indicates whether the Server should include instances of subtypes of the TypeDefinitionNode in the list of instances of the Node type.
dataToReturn []	QueryDataDescription	Specifies an Attribute or Reference from the originating typeDefinitionNode along a given relativePath for which to return data. This structure is defined in-line with the following indented items.
relativePath	RelativePath	Browse path relative to the originating Node that identifies the Node which contains the data that is being requested, where the originating Node is an instance Node of the type defined by the type definition Node. The instance Nodes are further limited by the filter provided as part of this call. For a definition of relativePath see 7.30. This relative path could end on a Reference, in which case the ReferenceDescription of the Reference would be returned as its value. The targetName field of the relativePath may contain a type NodeId. This is done by setting the namespaceIndex of the targetName to zero and the name part of the targetName to the XML representation of the NodeId. The XML representation is defined in OPC 10000-6. When matching instances are returned as the target node, the target node should be an instance of the specified type or subtype of the specified type.
attributeId	IntegerId	Id of the Attribute. This should be a valid Attribute Id. The IntegerId is defined in 7.19. The IntegerId for Attributes are defined in OPC 10000-6. If the RelativePath ended in a Reference then this parameter is 0 and ignored by the Server.
indexRange	NumericRange	This parameter is used to identify a single element of a structure or an array, or a single range of indexes for arrays. If a range of elements are specified, the values are returned as a composite. The first element is identified by index 0 (zero). The NumericRange type is defined in 7.27. This parameter is null or empty if the specified Attribute is not an array or a structure. However, if the specified Attribute is an array or a structure, and this parameter is null or empty, then all elements are to be included in the range.
Filter	ContentFilter	Resulting Nodes should be limited to the Nodes matching the criteria defined by the filter. ContentFilter is discussed in 7.7. If an empty filter is provided then the entire AddressSpace should be examined and all Nodes that contain a matching requested Attribute or Reference are returned.
maxDataSetsToReturn	Counter	The number of QueryDataSets that the Client wants the Server to return in the response and on each subsequent continuation call response. The Server is allowed to further limit the response, but should not exceed this limit. A value of 0 indicates that the Client is imposing no limitation.
maxReferencesToReturn	Counter	The number of References that the Client wants the Server to return in the response for each QueryDataSet and on each subsequent continuation call response. The Server is allowed to further limit the response, but should not exceed this limit. A value of 0 indicates that the Client is imposing no limitation. For example a result where 4 Nodes are being returned, but each has 100 References, if this limit were set to 50 then only the first 50 References for each Node would be returned on the initial call and a continuation point would be set indicating additional data.

Table B.4 – QueryFirst Response Parameters

Name	Type	Description
Response
responseHeader	ResponseHeader	Common response parameters (see 7.33 for ResponseHeader definition).
queryDataSets []	QueryDataSet	The array of QueryDataSets. This array is empty if no Nodes or References met the nodeTypes criteria. In this case the continuationPoint parameter should be empty. The QueryDataSet type is defined in B.2.5.
continuationPoint	ContinuationPoint	Server-defined opaque value that identifies the continuation point. The continuation point is used only when the Query results are too large to be returned in a single response. “Too large” in this context means that the Server is not able to return a larger response or that the number of QueryDataSets to return exceeds the maximum number of QueryDataSets to return that was specified by the Client in the request. The continuation point is used in the QueryNext Service. When not used, the value of this parameter is null or empty. If a continuation point is returned, the Client should call QueryNext to get the next set of QueryDataSets or to free the resources for the continuation point in the Server. A continuation point should remain active until the Client passes the continuation point to QueryNext or the session is closed. If the maximum continuation points have been reached the oldest continuation point should be reset. The ContinuationPoint type is described in 7.9.
parsingResults[]	ParsingResult	List of parsing results for QueryFirst. The size and order of the list matches the size and order of the NodeTypes request parameter. This structure is defined in-line with the following indented items. This list is populated with any status codes that are related to the processing of the node types that are part of the query. The array can be empty if no errors where encountered. If any node type encountered an error all node types should have an associated status code.
statusCode	StatusCode	Parsing result for the requested NodeTypeDescription.
dataStatusCodes []	StatusCode	List of results for dataToReturn. The size and order of the list matches the size and order of the dataToReturn request parameter. The array can be empty if no errors where encountered.
dataDiagnosticInfos []	DiagnosticInfo	List of diagnostic information dataToReturn (see 7.12 for DiagnosticInfo definition). The size and order of the list matches the size and order of the dataToReturn request parameter. This list is empty if diagnostics information was not requested in the request header or if no diagnostic information was encountered in processing of the query request.
diagnosticInfos []	DiagnosticInfo	List of diagnostic information for the requested NodeTypeDescription. This list is empty if diagnostics information was not requested in the request header or if no diagnostic information was encountered in processing of the query request.
filterResult	ContentFilter Result	A structure that contains any errors associated with the filter. This structure should be empty if no errors occurred. The ContentFilterResult type is defined in 7.7.2.

If the Query is invalid or cannot be processed, then QueryDataSets are not returned and only a Service result, filterResult, parsingResults and optional DiagnosticInfo is returned. Table B.5 defines the Service results specific to this Service. Common StatusCodes are defined in Table 176.

Table B.5 – QueryFirst Service Result Codes

Symbolic Id	Description
Bad_NothingToDo	See Table 176 for the description of this result code.
Bad_TooManyOperations	See Table 176 for the description of this result code.
Bad_ContentFilterInvalid	See Table 177 for the description of this result code.
Bad_ViewIdUnknown	See Table 176 for the description of this result code.
Bad_ViewTimestampInvalid	See Table 176 for the description of this result code.
Bad_ViewParameterMismatchInvalid	See Table 176 for the description of this result code.
Bad_ViewVersionInvalid	See Table 176 for the description of this result code.
Bad_InvalidFilter	The provided filter is invalid, see the filterResult for specific errors
Bad_NodelistError	The NodeTypes provided contain an error, see the parsingResults for specific errors
Bad_InvalidView	The provided ViewDescription is not a valid ViewDescription.
Good_ResultsMayBeIncomplete	The Server should have followed a reference to a node in a remote Server but did not. The result set may be incomplete.

Table B.6 defines values for the parsingResults statusCode parameter that are specific to this Service. Common StatusCodes are defined in Table 177.

Table B.6 – QueryFirst Operation Level Result Codes

Symbolic Id	Description
Bad_NodeIdInvalid	See Table 177 for the description of this result code.
Bad_NodeIdUnknown	See Table 177 for the description of this result code.
Bad_NotTypeDefinition	The provided NodeId was not a type definition NodeId.
Bad_AttributeIdInvalid	See Table 177 for the description of this result code.
Bad_IndexRangeInvalid	See Table 177 for the description of this result code.

B.2.4 QueryNext

This Service is used to request the next set of QueryFirst or QueryNext response information that is too large to be sent in a single response. “Too large” in this context means that the Server is not able to return a larger response or that the number of QueryDataSets to return exceeds the maximum number of QueryDataSets to return that was specified by the Client in the original request. The QueryNext should be submitted on the same session that was used to submit the QueryFirst or QueryNext that is being continued.

Table B.7 defines the parameters for the Service.

Table B.7 – QueryNext Service Parameters

Name	Type	Description
Request
requestHeader	Request Header	Common request parameters (see 7.32 for RequestHeader definition).
releaseContinuationPoint	Boolean	A Boolean parameter with the following values: TRUEpassed continuationPoint should be reset to free resources for the continuation point in the Server. FALSEpassed continuationPoint should be used to get the next set of QueryDataSets. A Client should always use the continuation point returned by a QueryFirst or QueryNext response to free the resources for the continuation point in the Server. If the Client does not want to get the next set of Query information, QueryNext should be called with this parameter set to TRUE. If the parameter is set to TRUE all array parameters in the response should contain empty arrays.
continuationPoint	ContinuationPoint	Server defined opaque value that represents the continuation point. The value of the continuation point was returned to the Client in a previous QueryFirst or QueryNext response. This value is used to identify the previously processed QueryFirst or QueryNext request that is being continued, and the point in the result set from which the browse response is to continue. The ContinuationPoint type is described in 7.9.

Response
responseHeader	Response Header	Common response parameters (see 7.33 for ResponseHeader definition).
queryDataSets []	QueryDataSet	The array of QueryDataSets. The QueryDataSet type is defined in B.2.5.
revisedContinuationPoint	ContinuationPoint	Server-defined opaque value that represents the continuation point. It is used only if the information to be returned is too large to be contained in a single response. When not used or when releaseContinuationPoint is set, the value of this parameter is null or empty. The ContinuationPoint type is described in 7.9.

Table B.8 defines the Service results specific to this Service. Common StatusCodes are defined in Table 176.

Table B.8 – QueryNext Service Result Codes

Symbolic Id	Description
Bad_ContinuationPointInvalid	See Table 177 for the description of this result code.

B.2.5 QueryDataSet

The components of this parameter are defined in Table B.9.

Table B.9 – QueryDataSet

Name	Type	Description
QueryDataSet	structure	Data related to a Node returned in a Query response.
nodeId	ExpandedNodeId	The NodeId for this Node description.
typeDefinitionNode	ExpandedNodeId	The NodeId for the type definition for this Node description.
values []	BaseDataType	Values for the selected Attributes. The order of returned items matches the order of the requested items. There is an entry for each requested item for the given TypeDefinitionNode that matches the selected instance, this includes any related nodes that were specified using a relative path from the selected instance’s TypeDefinitionNode. If no values where found for a given requested item a null value is returned for that item. If a value has a bad status, the StatusCode is returned instead of the value. If multiple values exist for a requested item then an array of values is returned. If the requested item is a reference then a ReferenceDescription or array of ReferenceDescription is returned for that item. If the QueryDataSet is returned in a QueryNext to continue a list of ReferenceDescription, the values array will have the same size but the other values already returned are null.

B.3 Complex Examples of Query Filters

B.3.1 Overview

These query examples illustrate complex filters. The following conventions apply to these examples with regard to Attribute operands (for a definition of these operands, see 7.7.4).

AttributeOperand: Refers to a Node, an Attribute of a Node or the Value Attribute of a Property associated with a Node. In the examples character names of ExpandedNodeId are used instead of an actual ExpandedNodeId, this also applies to Attribute Ids.
The string representation of relative paths is used instead of the actual structure.
The NamespaceIndex used in all examples is 12 (it could just as easily have been 4 or 23 or any value). For more information about NamespaceIndex, see OPC 10000-3. The use of the NamespaceIndex illustrates that the information model being used in the examples is not a model defined by this document, but one created for the examples.

B.3.2 Used type model

The following examples use the type model described below. All Property values are assumed to be string unless otherwise noted

New Reference types:

"HasChild" derived from HierarchicalReference.

"HasAnimal" derived from HierarchicalReference.

"HasPet" derived from HasAnimal.

"HasFarmAnimal" derived from HasAnimal.

"HasSchedule" derived from HierarchicalReference.

PersonType derived from BaseObjectType adds:

HasProperty "LastName".

HasProperty "FirstName".

HasProperty "StreetAddress".

HasProperty "City".

HasProperty "ZipCode".

May have HasChild reference to a node of type PersonType.

May have HasAnimal reference to a node of type AnimalType (or a subtype of this Reference type).

AnimalType derived from BaseObjectType adds:

May have HasSchedule reference to a node of type FeedingScheduleType.

HasProperty "Name".

DogType derived from AnimalType adds:

HasProperty "NickName".

HasProperty "DogBreed".

HasProperty "License".

CatType derived from AnimalType adds:

HasProperty "NickName".

HasProperty "CatBreed".

PigType derived from AnimalType adds:

HasProperty "PigBreed".

ScheduleType derived from BaseObjectType adds:

HasProperty "Period".

FeedingScheduleType derived from ScheduleType adds:

HasProperty "Food".

HasProperty "Amount" (Stored as an Int32).

AreaType derived from BaseObjectType is just a simple Folder and contains no Properties.

This example type system is shown in Figure B.3. In this Figure, the OPC UA notation is used for all References to ObjectTypes, Variables, Properties and subtypes. Additionally, supported References are contained in an inner box. The actual references only exist in the instances, thus, no connections to other Objects are shown in the Figure and they are subtypes of the listed Reference.

Figure B.3 – Example Type Nodes

A corresponding example set of instances is shown in Figure B.4. These instances include a type Reference for Objects. Properties also have type References, but the References are omitted for simplicity. The name of the Object is provided in the box and a numeric instance NodeId in brackets. Standard ReferenceTypes use the OPC UA notation, custom ReferenceTypes are listed as a named Reference. For Properties, the BrowseName, NodeId, and Value are shown. The Nodes that are included in a View (View1) are enclosed in the coloured box. Two Area nodes are included for grouping of the existing person nodes. All custom nodes are defined in namespace 12 which is not included in Figure B.4.

Figure B.4 – Example Instance Nodes

B.3.3 Example Notes

For all of the examples in 7.7.4, the type definition Node is listed in its symbolic form, in the actual call it would be the ExpandedNodeId assigned to the Node. The Attribute is the symbolic name of the Attribute, in the actual call they would be translated to the IntegerId of the Attribute. Also in all of the examples the BrowseName is included in the result table for clarity; normally this would not be returned.

All of the examples include the following items:

an English description of the object of the query;
an SQL like description of the query;
a table that has a NodeTypeDescription of the items that are to be returned;
a figure illustrating the query filter;
a table describing the content filter;
a table describing the resulting dataset.

The examples assume namespace 12 is the namespace for all of the custom definitions described for the examples.

B.3.4 Example 1

This example requests a simple layered filter, a person has a pet and the pet has a schedule.

Example 1: Get PersonType.LastName, AnimalType.Name, ScheduleType.Period where the Person Has a Pet and that Pet Has a Schedule.

The NodeTypeDescription parameters used in the example are described in Table B.10.

Table B.10 – Example 1 NodeTypeDescription

Type Definition Node	Include Subtypes	QueryDataDescription
Type Definition Node	Include Subtypes	Relative Path	Attribute	Index Range
PersonType	FALSE	“.12:LastName”	value	N/A
		“<12:HasPet>12:AnimalType. 12:Name”	value	N/A
		“<12:HasPet>12:AnimalType<12:HasSchedule> 12:Schedule. 12:Period”	value	N/A

The corresponding ContentFilter is illustrated in Figure B.5.

Figure B.5 – Example 1 Filter

Table B.11 describes the ContentFilter elements, operators and operands used in the example.

Table B.11 – Example 1 ContentFilter

Element[]	Operator	Operand[0]	Operand[1]	Operand[2]	Operand[3]
1	RelatedTo	AttributeOperand = NodeId: PersonType, BrowsePath “.”, Attribute: NodeId	ElementOperand = 2	AttributeOperand = NodeId: HasPet, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’
2	RelatedTo	AttributeOperand = NodeId: AnimalType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: ScheduleType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: HasSchedule, BrowsePath “.”, Attribute: NodeId	LiteralOperand= ‘1’

Table B.12 describes the QueryDataSet that results from this query if it were executed against the instances described in Figure B.4

Table B.12 – Example 1 QueryDataSets

NodeId	TypeDefinition NodeId	RelativePath	Value
12:30 (JFamily1)	PersonType	“.12:LastName”	Jones
		“<12:HasPet>12:AnimalType. 12:Name”	Rosemary
		“<12:HasPet>12:AnimalType. 12:Name”	Basil
		“<12:HasPet>12:AnimalType<12:HasSchedule> 12:Schedule.12:Period”	Hourly
			Daily
12:42(HFamily1)	PersonType	“.12:LastName”	Hervey
		“<12:HasPet>12:AnimalType. 12:Name”	Oliver
		“<12:HasPet>12:AnimalType<12:HasSchedule> 12:Schedule.12:Period”	Daily

NOTE The RelativePath column and browse name (in parentheses in the NodeId column) are not in the QueryDataSet and are only shown here for clarity. The TypeDefinition NodeId would be an integer not the symbolic name that is included in the table.

The Value column is returned as an array for each Node description, where the order of the items in the array would correspond to the order of the items that were requested for the given Node Type. In Addition, if a single Attribute has multiple values then it would be returned as an array within the larger array, for example in this table Rosemary and Basil would be returned in a array for the .<HasPet>.AnimalType.Name item. They are show as separate rows for ease of viewing. The actual value array for JFamily1 would be (“Jones”, {“RoseMary”, ”Basil”}, {“Hourly”, “Daily”})

B.3.5 Example 2

The second example illustrates receiving a list of disjoint Nodes and also illustrates that an array of results can be received.

Example 2: Get PersonType.LastName, AnimalType.Name where a person has a child or (a pet is of type cat and has a feeding schedule).

The NodeTypeDescription parameters used in the example are described in Table B.13.

Table B.13 – Example 2 NodeTypeDescription

Type Definition Node	Include Subtypes	QueryDataDescription
Type Definition Node	Include Subtypes	Relative Path	Attribute	Index Range
PersonType	FALSE	“.12:LastName”	Value	N/A
AnimalType	TRUE	“.12:Name”	Value	N/A

The corresponding ContentFilter is illustrated in

Figure B.6.

Figure B.6 – Example 2 filter logic tree

Table B.14 describes the elements, operators and operands used in the example. It is worth noting that a CatType is a subtype of AnimalType.

Table B.14 – Example 2 ContentFilter

Element[]	Operator	Operand[0]	Operand[1]	Operand[2]	Operand[3]
0	Or	ElementOperand=1	ElementOperand = 2
1	RelatedTo	AttributeOperand = NodeId: PersonType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: PersonType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: HasChild, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’
2	RelatedTo	AttributeOperand = NodeId: CatType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: FeedingScheduleType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: HasSchedule, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’

The results from this query would contain the QueryDataSets shown in Table B.15.

Table B.15 – Example 2 QueryDataSets

NodeId	TypeDefinition NodeId	RelativePath	Value
12:30 (Jfamily1)	PersonType	. 12:LastName	Jones
12:42 (HFamily1)	PersonType	. 12:LastName	Hervey
12:48 (HFamily2)	PersonType	. 12:LastName	Hervey
12:70 (Cat1)	CatType	. 12:Name	Rosemary
12:74 (Cat2)	CatType	. 12:Name	Basil

NOTE The relative path column and browse name (in parentheses in the NodeId column) are not in the QueryDataSet and are only shown here for clarity. The TypeDefinition NodeId would be a NodeId not the symbolic name that is included in the table.

B.3.6 Example 3

The third example provides a more complex Query in which the results are filtered on multiple criteria.

Example 3: Get PersonType.LastName, AnimalType.Name, ScheduleType.Period where a person has a pet and the animal has a feeding schedule and the person has a Zipcode = ‘02138’ and (the Schedule.Period is Daily or Hourly) and Amount to feed is > 10.

Table B.16 describes the NodeTypeDescription parameters used in the example.

Table B.16 – Example 3 - NodeTypeDescription

Type Definition Node	Include Subtypes	QueryDataDescription
Type Definition Node	Include Subtypes	RelativePath	Attribute	Index Range
PersonType	FALSE	“12:LastName”	Value	N/A
		“<12:HasPet>12:AnimalType. 12:Name”	Value	N/A
		“<12:HasPet>12:AnimalType<12:HasSchedule> 12:FeedingSchedule.Period”	Value	N/A

The corresponding ContentFilter is illustrated in Figure B.7.

Figure B.7 – Example 3 filter logic tree

Table B.17 describes the elements, operators and operands used in the example.

Table B.17 – Example 3 ContentFilter

Element[]	Operator	Operand[0]	Operand[1]	Operand[2]	Operand[3]
0	And	Element Operand= 1	ElementOperand = 2
1	And	ElementOperand = 4	ElementOperand = 6
2	And	ElementOperand = 3	ElementOperand = 9
3	Or	ElementOperand = 7	ElementOperand = 8
4	RelatedTo	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	ElementOperand = 5	AttributeOperand = NodeId: 12:HasPet, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’
5	RelatedTo	AttributeOperand = Node: 12:AnilmalType, BrowsePath “.”, Attribute: NodeId Alias: AT	AttributeOperand = NodeId: 12:FeedingScheduleType, BrowsePath “.”, Attribute: NodeId Alias: FST	AttributeOperand = NodeId: 12:HasSchedule, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’
6	Equals	AttributeOperand = NodeId: 12:PersonType BrowsePath 12:Zipcode “.”, Attribute: Value	LiteralOperand = ‘02138’
7	Equals	AttributeOperand = NodeId: 12:PersonType BrowsePath “12:HasPet>12:AnimalType<12:HasSchedule>12: FeedingSchedule/12:Period”, Attribute: Value Alias: FST	LiteralOperand = ‘Daily’
8	Equals	AttributeOperand = NodeId: 12:PersonType BrowsePath “12:HasPet>12:AnimalType<12:HasSchedule>12: FeedingSchedule/12:Period”, Attribute: Value Alias: FST	LiteralOperand = ‘Hourly’
9	Greater Than	AttributeOperand = NodeId: 12:PersonType BrowsePath “12:HasPet>12:AnimalType<12:HasSchedule>12: FeedingSchedule/12:Amount”, Attribute: Value Alias: FST	ElementOperand = 10
10	Cast	LiteralOperand = 10	AttributeOperand = NodeId: Int32, BrowsePath “.”, Attribute: NodeId

The results from this query would contain the QueryDataSets shown in Table B.18.

Table B.18 – Example 3 QueryDataSets

NodeId	TypeDefinition NodeId	RelativePath	Value
12:30 (JFamily1)	PersonType	“.12:LastName”	Jones
		“<12:HasPet>12:PersonType. 12:Name”	Rosemary
		“<12:HasPet>12:PersonType. 12:Name”	Basil
		“<12:HasPet>12:AnimalType<12:HasSchedule>12:FeedingSchedule. 12:Period”	Hourly
			Daily

NOTE The RelativePath column and browse name (in parentheses in the NodeId column) are not in the QueryDataSet and are only shown here for clarity. The TypeDefinition NodeId would be an integer not the symbolic name that is included in the table.

B.3.7 Example 4

The fourth example provides an illustration of the Hop parameter that is part of the RelatedTo Operator.

Example 4: Get PersonType.LastName where a person has a child who has a child who has a pet.

Table B.19 describes the NodeTypeDescription parameters used in the example.

Table B.19 – Example 4 NodeTypeDescription

Type Definition Node	Include Subtypes	QueryDataDescription
Type Definition Node	Include Subtypes	Relative Path	Attribute	Index Range
PersonType	FALSE	“.12:LastName”	value	N/A

The corresponding ContentFilter is illustrated in Figure B.8.

Figure B.8 – Example 4 filter logic tree

Table B.20 describes the elements, operators and operands used in the example.

Table B.20 – Example 4 ContentFilter

Element[]	Operator	Operand[0]	Operand[1]	Operand[2]	Operand[3]
0	RelatedTo	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	Element Operand = 1	AttributeOperand = NodeId: 12:HasChild, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘2’
1	RelatedTo	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:AnimalType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:HasPet, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’

The results from this query would contain the QueryDataSets shown in Table B.21. It is worth noting that the pig “Pig1” is referenced as a pet by Sara, but is referenced as a farm animal by Sara’s parent Paul.

Table B.21 – Example 4 QueryDataSets

NodeId	TypeDefinition NodeId	RelativePath	Value
12:42 (HFamily1)	PersonType	“.12:LastName”	Hervey

NOTE The RelativePath column and browse name (in parentheses in the NodeId column) are not in the QueryDataSet and are only shown here for clarity. The TypeDefinition NodeId would be an integer not the symbolic name that is included in the table.

B.3.8 Example 5

The fifth example provides an illustration of the use of alias.

Example 5: Get the last names of children that have the same first name as a parent of theirs

Table B.22 describes the NodeTypeDescription parameters used in the example.

Table B.22 – Example 5 NodeTypeDescription

Type Definition Node	Include Subtypes	QueryDataDescription
Type Definition Node	Include Subtypes	Relative Path	Attribute	Index Range
PersonType	FALSE	“<12:HasChild>12:PersonType. 12:LastName”	Value	N/A

The corresponding ContentFilter is illustrated in Figure B.9.

Figure B.9 – Example 5 filter logic tree

In this example, one Reference to PersonType is aliased to “Parent” and another Reference to PersonType is aliased to “Child”. The value of Parent.firstName and Child.firstName are then compared. Table B.23 describes the elements, operators and operands used in the example.

Table B.23 – Example 5 ContentFilter

Element[]	Operator	Operand[0]	Operand[1]	Operand[2]	Operand[3}
0	And	ElementOperand = 1	ElementOperand = 2
1	RelatedTo	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId, Alias: “Parent”	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId, Alias: “Child”	AttributeOperand = NodeId: 12:HasChild, Attribute: NodeId	LiteralOperand = “1”
2	Equals	AttributeOperand = NodeId: 12:PersonType, BrowsePath ““/12:FirstName”, Attribute: Value, Alias: “Parent”	AttributeOperand = NodeId: 12:PersonType, BrowsePath ““/12:FirstName”, Attribute: Value, Alias: “Child”

The results from this query would contain the QueryDataSets shown in Table B.24.

Table B.24 – Example 5 QueryDataSets

NodeId	TypeDefinition NodeId	RelativePath	Value
12:42 (HFamily1)	PersonType	“<12:HasChild>12:PersonType.12:LastName”	Hervey

B.3.9 Example 6

The sixth example provides an illustration a different type of request, one in which the Client is interested in displaying part of the AddressSpace of the Server. This request includes listing a Reference as something that is to be returned.

Example 6: Get PersonType.NodeId, AnimalType.NodeId, PersonType.HasChild Reference, PersonType.HasAnimal Reference where a person has a child who has a Animal.

Table B.25 describes the NodeTypeDescription parameters used in the example.

Table B.25 – Example 6 NodeTypeDescription

Type Definition Node	Include Subtypes	QueryDataDescription
Type Definition Node	Include Subtypes	Relative Path	Attribute	Index Range
PersonType	FALSE	“.12:NodeId”	value	N/A
		<12:HasChild>12:PersonType<12:HasAnimal>12:AnimalType.NodeId	value	N/A
		<12:HasChild>	value	N/A
		<12:HasChild>12:PersonType<12:HasAnimal>	value	N/A

The corresponding ContentFilter is illustrated in Figure B.10.

Figure B.10 – Example 6 filter logic tree

Table B.26 describes the elements, operators and operands used in the example.

Table B.26 – Example 6 ContentFilter

Element[]	Operator	Operand[0]	Operand[1]	Operand[2]	Operand[3]
0	RelatedTo	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	ElementOperand = 1	AttributeOperand = Node: 12:HasChild, BrowsePath “.”,Attribute:NodeId	LiteralOperand = ‘1’
1	RelatedTo	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:AnimalType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:HasAnimal, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’

The results from this query would contain the QueryDataSets shown in Table B.27.

Table B.27 – Example 6 QueryDataSets

NodeId	TypeDefinition NodeId	RelativePath	Value
12:42 (HFamily1)	PersonType	“.NodeId”	12:42 (HFamily1)
		<12:HasChild>12:PersonType<12:HasAnimal> 12:AnimalType.NodeId	12:91 (Pig1)
		<12:HasChild>	HasChild ReferenceDescription
		<12:HasChild>12:PersonType<12:HasAnimal>	HasFarmAnimal ReferenceDescription
12:48 (HFamily2)	PersonType	“.NodeId”	12:48 (HFamily2)
		<12:HasChild>12:PersonType<12:HasAnimal> 12:AnimalType.NodeId	12:91 (Pig1)
		<12:HasChild>	HasChild ReferenceDescription
		<12:HasChild>12:PersonType<12:HasAnimal>	HasPet ReferenceDescription

NOTE The RelativePath and browse name (in parentheses) is not in the QueryDataSet and is only shown here for clarity and the TypeDefinition NodeId would be an integer, not the symbolic name that is included in the table. The value field would in this case be the NodeId where it was requested, but for the example the browse name is provided in parentheses and in the case of Reference types on the browse name is provided. For the References listed in Table B.27, the value would be a ReferenceDescription which are described in 7.29.

Table B.28 provides an example of the same QueryDataSet as shown in Table B.27 without any additional fields and minimal symbolic Ids. There is an entry for each requested Attribute, in the cases where an Attribute would return multiple entries the entries are separated by comas. If a structure is being returned then the structure is enclosed in square brackets. In the case of a ReferenceDescription the structure contains a structure and DisplayName and BrowseName are assumed to be the same and defined in Figure B.4.

Table B.28 – Example 6 QueryDataSets without additional information

NodeId	TypeDefinition NodeId	Value
12:42	PersonType	12:42
		12:91
		[HasChild,TRUE,[48,HFamily2,HFamily2,PersonType]],
		[HasFarmAnimal,TRUE[91,Pig1,Pig1,PigType]
12:48	PersonType	12:54
		12:91
		[HasChild,TRUE,[ 54,HFamily3,HFamily3,PersonType]]
		[HasPet, TRUE,[ 91,Pig1,Pig1,PigType]]

The PersonType, HasChild, PigType, HasPet, HasFarmAnimal identifiers used in the above table would be translated to actual ExpandedNodeId.

B.3.10 Example 7

The seventh example provides an illustration a request in which a Client wants to display part of the AddressSpace based on a starting point that was obtained via browsing. This request includes listing References as something that is to be returned. In this case the Person Browsed to Area2 and wanted to Query for information below this starting point.

Example 7: Get PersonType.NodeId, AnimalType.NodeId, PersonType.HasChild Reference, PersonType.HasAnimal Reference where the person is in Area2 (Cleveland nodes) and the person has a child.

Table B.29 describes the NodeTypeDescription parameters used in the example.

Table B.29 – Example 7 NodeTypeDescription

Type Definition Node	Include Subtypes	QueryDataDescription
Type Definition Node	Include Subtypes	Relative Path	Attribute	Index Range
PersonType	FALSE	“.NodeId”	Value	N/A
		<12:HasChild>	Value	N/A
		<12:HasAnimal>NodeId	Value	N/A
		<12:HasAnimal>	Value	N/A

The corresponding ContentFilter is illustrated in Figure B.11. Note that the Browse call would typically return a NodeId, thus the first filter is for the BaseObjectType with a NodeId of 95 where 95 is the NodeId associated with the Area2 node, all Nodes descend from BaseObjectType, and NodeId is a base Property so this filter will work for all Queries of this nature.

Figure B.11 – Example 7 filter logic tree

Table B.30 describes the elements, operators and operands used in the example.

Table B.30 – Example 7 ContentFilter

Element[]	Operator	Operand[0]	Operand[1]	Operand[2]	Operand[3]
0	RelatedTo	ElementOperand = 2	ElementOperand = 1	AttributeOperand = Node:HierachicalReference, BrowsePath “.”, Attribute:NodeId	LiteralOperand = ‘1’
1	RelatedTo	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:HasChild, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’
2	Equals	AttributeOperand = NodeId: BaseObjectType, BrowsePath “.”, Attribute: NodeId,	LiteralOperand = ‘95

The results from this Query would contain the QueryDataSets shown in Table B.31.

Table B.31 – Example 7 QueryDataSets

NodeId	TypeDefinition NodeId	RelativePath	Value
12:42 (HFamily1)	PersonType	“.NodeId”	12:42 (HFamily1)
		<12:HasChild>	HasChild ReferenceDescription
		<12:HasAnimal>12:AnimalType.NodeId	NULL
		<12:HasAnimal>	HasFarmAnimal ReferenceDescription
12:48 (HFamily2)	PersonType	“.NodeId”	12:48 (HFamily2)
		<12:HasChild>	HasChild ReferenceDescription
		<12:HasAnimal>12:AnimalType.NodeId	12:91 (Pig1)
		<12:HasAnimal>	HasFarmAnimal ReferenceDescription

NOTE The RelativePath and browse name (in parentheses) is not in the QueryDataSet and is only shown here for clarity and the TypeDefinition NodeId would be an integer not the symbolic name that is included in the table. The value field would in this case be the NodeId where it was requested, but for the example the browse name is provided in parentheses and in the case of Reference types on the browse name is provided. For the References listed in Table B.31, the value would be a ReferenceDescription which are described in 7.29.

B.3.11 Example 8

The eighth example provides an illustration of a request in which the AddressSpace is restricted by a Server defined View. This request is the same as in the second example which illustrates receiving a list of disjoint Nodes and also illustrates that an array of results can be received. It is important to note that all of the parameters and the ContentFilter are the same, only the View description would be specified as “View1”.

Example 8: Get PersonType.LastName, AnimalType.Name where a person has a child or (a pet is of type cat and has a feeding schedule) limited by the AddressSpace in View1.

The NodeTypeDescription parameters used in the example are described in Table B.32

Table B.32 – Example 8 NodeTypeDescription

Type Definition Node	Include Subtypes	QueryDataDescription
Type Definition Node	Include Subtypes	Relative Path	Attribute	Index Range
PersonType	FALSE	“.12:LastName”	value	N/A
AnimalType	TRUE	“12.Name”	value	N/A

The corresponding ContentFilter is illustrated in Figure B.12.

Figure B.12 – Example 8 filter logic tree

Table B.33 describes the elements, operators and operands used in the example. It is worth noting that a CatType is a subtype of AnimalType.

Table B.33 – Example 8 ContentFilter

Element[]	Operator	Operand[0]	Operand[1]	Operand[2]	Operand[3]
0	Or	ElementOperand=1	ElementOperand = 2
1	RelatedTo	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:HasChild, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’
2	RelatedTo	AttributeOperand = NodeId: 12:CatType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:FeedingScheduleType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:HasSchedule, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’

The results from this query would contain the QueryDataSets shown in Table B.34. If this is compared to the result set from example 2, the only difference is the omission of the Cat Nodes. These Nodes are not in the View and thus are not included in the result set.

Table B.34 – Example 8 QueryDataSets

NodeId	TypeDefinition NodeId	RelativePath	Value
12:30 (Jfamily1)	Persontype	.12:LastName	Jones

B.3.12 Example 9

The ninth example provides a further illustration for a request in which the AddressSpace is restricted by a Server defined View. This request is similar to the second example except that some of the requested nodes are expressed in terms of a relative path. It is important to note that the ContentFilter is the same, only the View description would be specified as “View1”.

Example 9: Get PersonType.LastName, AnimalType.Name where a person has a child or (a pet is of type cat and has a feeding schedule) limited by the AddressSpace in View1.

Table B.35 describes the NodeTypeDescription parameters used in the example.

Table B.35 – Example 9 NodeTypeDescription

Type Definition Node	Include Subtypes	QueryDataDescription
		Relative Path	Attribute		Index Range
PersonType	FALSE	“.NodeId”		value		N/A
		<12:HasChild>12:PersonType<12:HasAnimal>12:AnimalType.NodeId		value		N/A
		<12:HasChild>		value		N/A
		<12:HasChild>12:PersonType <12:HasAnimal>		value		N/A
PersonType	FALSE	“.12:LastName”		value		N/A
		<12:HasAnimal>12:AnimalType. 12:Name		value		N/A
AnimalType	TRUE	“.12:name”		value		N/A

The corresponding ContentFilter is illustrated in Figure B.13

Figure B.13 – Example 9 filter logic tree

Table B.36 describes the elements, operators and operands used in the example.

Table B.36 – Example 9 ContentFilter

Element[]	Operator	Operand[0]	Operand[1]	Operand[2]	Operand[3]
0	Or	ElementOperand=1	ElementOperand = 2
1	RelatedTo	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:PersonType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:HasChild, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’
2	RelatedTo	AttributeOperand = NodeId: 12:CatType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:FeedingScheduleType, BrowsePath “.”, Attribute: NodeId	AttributeOperand = NodeId: 12:HasSchedule, BrowsePath “.”, Attribute: NodeId	LiteralOperand = ‘1’

The results from this Query would contain the QueryDataSets shown in Table B.37. If this is compared to the result set from example 2, the Pet Nodes are included in the list, even though they are outside of the View. This is possible since the name referenced via the relative path and the root Node is in the View.

Table B.37 – Example 9 QueryDataSets

NodeId	TypeDefinition NodeId	RelativePath	Value
12:30 (Jfamily1)	PersonType	. 12:LastName	Jones
		<12:HasAnimal>12:AnimalType. 12:Name	Rosemary
		<12:HasAnimal>12:AnimalType. 12:Name	Basil

NOTE The RelativePath column and browse name (in parentheses in the NodeId column) are not in the QueryDataSet and are only shown here for clarity. The TypeDefinition NodeId would be an integer not the symbolic name that is included in the table.

______________