Action Item 18. Revised discussion of Dialects

[peter_niblett@uk.ibm.com]

 Action Item 18. Examination of wsrp:dialect

The attribute wsrp:dialect appears in the definition of wsrp:QueryExpressionType. This
type is currently used in BaseNotification for the precondition and
selector that appear as Subscription properties and in the subscribe
message.

wsrp:QueryExpressionType has the following definition

<xsd:complexType name="QueryExpressionType" mixed="true">
 <xsd:sequence>
      <xsd:any minOccurs="0" maxOccurs="1" processContents="lax" />
 </xsd:sequence>
 <xsd:attribute name="Dialect" type="xsd:anyURI" />
</xsd:complexType>

Note that BaseNotification uses a similar kind of dialected type for TopicExpressions. Unlike the QueryExpressionType, this one comes from the WSBN namespace 
 
 <xsd:complexType name="TopicExpressionType" mixed="true">
    <xsd:sequence>
      <xsd:any minOccurs="0" maxOccurs="1" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="Dialect" type="xsd:anyURI" />
  </xsd:complexType>

The rationale for reusing wsrp:QueryExpressionType as the type for Selector and Precondition is

1. The syntax provides what we need for Selector and Precondition
2. There's a close similarity between the semantics of the Precondition
element/property and the wsrp:QueryExpression, and a reasonable similarity
with the semantics of the Selector. Using a common schema type definition
emphasises this similarity.
3. It means that WSN does not have to define any Dialects for Selector and Precondition, or any URIs for these Dialects. WSRF-RP defines two "well-known" Dialects: http://www.w3.org/TR/1999/REC-xpath-19991116  and http://www.w3.org/TR/2003/WD-xpath20-20031112
4. If a third party wishes to define a new Dialect for wsrp, that Dialect then becomes 
automatically available for use with WSN with identical semantics. If we were to break the link then, at least in theory, it would be possible for someone to define a WSN selector Dialect, and a WSRF-RP query Dialect which had the same URI but different syntax and/or semantics depending which type it appears in.

On the other side of the balance it should be noted that

a)  This is now the only dependency that the BaseNotification xsd has on
the Resource Properties namespace. Breaking the dependency would simplify development tasks a little.

b)  As we noted TopicExpressions (which are also dialected) use a TopicExpressionType
which is defined in a WS-Notification namespace.  So a WSBN user might have to manipulate a mixture of wsn:Dialect and wsrp:Dialect attributes. However since the attributes are unqualified, I guess this does not cause too much of a problem.