Action Item 18, use of wsrp:Dialect

[Peter Niblett <peter_niblett@uk.ibm.com>]

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.