[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Action Item 18, use 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]