Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document will compare the XML language for expressing WS-Policies with the ways RDF extends XML. Further, it will describe how RDF meets document merging and extensibility goals described in the WS-Policy specification. In support of this, the document cites an RDF schema for representing web service policies. Examples allow direct comparison to the WS-Policy specification.
This document represents the position of the author with input from the members of the W3C Technology and Society domain. The document has not been endorsed by the W3C membership or team.
From the WS-Policy specification:
WS-Policy is a building block that is used in conjunction with other Web service and application-specific protocols to accommodate a wide variety of policy exchange models.
Web service discovery/negotiation/orchestration requires data describing the services. Examining WSDL and WS-Policy shows us how much work remains and how complex the problem space is. The details needed for an individual to decide whether or not to use an on-line bookstore are much simpler than those needed for a fund manager automatically purchasing foreign currencies. As we develop more protocols like WS-Policy and WSDL, we will have to define the pair-wise interaction between the new protocol and the set of existing specifications. This will be expensive, tedious, and time-consuming, and run the risk of changing the meaning of the earlier protocols.
This motivates the adoption of a language which allows us to minimize the need for pair-wise specification. Using RDF allows us to concentrate not on the syntax of how a policy is embedded in a web service description, but upon a simple graph model that visualizes like an entity relationship diagram. This elevates the discussion from the description of elements and attributes within other elements to the specification of relationships between entities.
XML defines a tree but provides some handy types (in both DTD and XSD) to create internal links. HTML familiarized people with graphs (trees with extra links) and most languages built on XML provide some mechanism to provide links to targets within documents. Within a WS-Policy, the /wsp:Policy/@wsu:Id, /wsp:Policy/@wsu:Id, /wsp:Policy/@TargetNamespace, /wsp:Policy/.../wsp:PolicyReference/@URI, and /wsp:Policy/.../wsp:PolicyReference/@Ref define two codings for internal links (QNames and URIs).
The RDF specification uses //@rdf:about, //@rdf:ID, and //@rdf:resource to perform internal and external links. (This loses the separation between QName and URI references, but the author is skeptical that having two addressing schemes is practical.)
The same mechanism is used for providing internal links in all RDF documents. This simplifies the specification of languages layered on RDF. Any RDF document may trivially link to nodes in a Creative Commons or P3P policy. A suite of web service description languages based on RDF would find that linking became a non-issue, saving specification time, coding time, and architecture complexity.
The WS-Policy specification defines a protocol for merging policies and portions of policies. This is not based on any standard protocol (for instance, XInclude) and will require custom code and some developer attention to corner cases (self-inclusion, etc.). Further, the semantics of inclusion are defined in terms of the impact on syntactic inclusion rather than a rigorous mathematical definition of graph inclusion as in the RDF Semantics document. Specifying document merging is not so easy that we should reinvent it without proper consideration.
Using RDF really doesn't complicate authoring, in fact, using existing RDF tools can greatly simplify tasks like visualization. Many XML document authors rely on tools that use closed content models expressed in DTD or XML Schema. (This author is lazy enough to use DTDs and sgmls to author SOAP.) Defining a content model that is parse-able as RDF provides the ability to use closed content validation (and prompting) while still seamlessly interacting with other RDF data.
Expressing concepts in RDF tends to promote comprehension, much as does expression in an entity relationship diagram. Real-world concepts are represented by nodes with relationships between them, rather than a hierarchical arrangement of elements and attributes. The graphical expression of an infoset is seldom as helpful as the graphical expression of an RDF graph (pun intended).
It should come as no surprise that this document promotes the expression of web service description languages in RDF. As the field of these languages grows, the heterogeneity of linking and conceptual models will produce exponential complexity in their interactions.
RDF provides a standard for merging documents with related data. If web services do not adopt the RDF model and document merging rules for this merge-able data, they will have to either pairwise define the interactions between each of the document formats that may directly interact. For instance, suppose the web services protocol suite were to define a protocol for expressing authentication details. It would be natural to use a term (perhaps a URI) to identify certain types of authentication, both for this (newly invented) protocol, and for policy (WS-Policy) requirements. Next, one may be tempted to define a homogeneous data model so that the parameters in the authentication protocol could be compared with those required in a policy.
WS-Policy uses an open content model on assertions to provide extensibility. The wsp:Usage attribute identifies the customary mandatory and optional semantics (as well as a third state which is a mandatory contraindication). The expression in RDF can still take advantage of these extensibility tools. RDF's subclass and subproperties can supplement this with an extra dimension to extensibility — re-use of derived assertions.
The following examples allow for comparison between the RDF expression policies to WS-Policy expressions.
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:wsp="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"
xmlns:p3p="http://www.w3.org/TR/p3p-rdfschema/"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsp:Policy>
<wsp:constrainedBy>
<wsp:ExactlyOne>
<wsp:constrainedBy>
<wsse:SecurityToken wsp:Preference="100">
<wsp:Usage rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Required"/>
<wsse:tokenType>wsse:Kerberosv5TGT</wsse:tokenType>
</wsse:SecurityToken>
</wsp:constrainedBy>
<wsp:constrainedBy>
<wsse:SecurityToken wsp:Preference="1">
<wsp:Usage rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Required"/>
<wsse:tokenType>wsse:X509v3</wsse:tokenType>
</wsse:SecurityToken>
</wsp:constrainedBy>
</wsp:ExactlyOne>
</wsp:constrainedBy>
<p3p:hasPolicy rdf:resource="http://foo.example/svcPolicy1"/>
</wsp:Policy>
</rdf:RDF>
From the Constraints and Capabilities for Web Services call for participation:
A Web service wishes to stipulate that clients are required support a reliable messaging protocol, and encrypt a specific header with WS-Security using a X.509 or user name security token in order to send an acceptable request message. Furthermore, the service has a P3P policy associated with its operations. Such constraints and capabilities might be associated with the Web service via a SOAP header or a WSDL file.
The interactions between entities modeled in RDF are expressed by relationship arcs. Saying that a WS-Policy has a p3p policy requires the invention of the arc to tie the wsp:Policy to a p3p:Policy. For illustration, we use p3p:hasPolicy:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:wsp="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"
xmlns:p3p="http://www.w3.org/TR/p3p-rdfschema/"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsp:Policy>
<wsp:constrainedBy>
<wsp:ExactlyOne>
<wsp:constrainedBy>
<wsse:SecurityToken wsp:Preference="100">
<wsp:Usage rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Required"/>
<wsse:tokenType>wsse:Kerberosv5TGT</wsse:tokenType>
</wsse:SecurityToken>
</wsp:constrainedBy>
<wsp:constrainedBy>
<wsse:SecurityToken wsp:Preference="1">
<wsp:Usage rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Required"/>
<wsse:tokenType>wsse:X509v3</wsse:tokenType>
</wsse:SecurityToken>
</wsp:constrainedBy>
</wsp:ExactlyOne>
</wsp:constrainedBy>
<p3p:hasPolicy rdf:resource="http://foo.example/svcPolicy1"/>
</wsp:Policy>
</rdf:RDF>
A frequent criticism of RDF is the syntactic overhead inherent in abstracting the data model. There is very little one can do to avoid this. No other encodings, from SOAP encoding to XDR, have been able to avoid this issue. It is the author's position that a 40% growth in document size is more than compensated for by the benefits of a common data model.
Clearly the scope of future work is infinite — it is up to popular consensus to decide when the diminishing returns of further specification are no longer worth standardization. At that point, the flexibility of organic RDF ontologies can take over, providing small communities with the tools they need to optimize their web service meda data. One point that does cry out for attention, however, is the correlation of a WS-Polciy with existing query facilities.
Policy and preference languages define data formats for expressing capabilities and establish criteria to be matched against those capabilities. WS-Policy focuses on the expression of criteria, leaving it up to the consumer of the policy to allow interaction with only the services that meet those criteria. A query that expresses those criteria enables the service, or the client, to test whether it meets those criteria. When viewed in the context of query, the section on Policy Assertion Sets looks very much like the results of a query:
| Assertions | ||||||||
| Acceptable |
|
|
|
|
||||
| Policy Sets | ||||||||
| Set 1 |
|
|
|
|
||||
| Set 2 |
|
|
|
|
||||
WS-Policy can be reduced to disjunctive normal form. Therefore, the WS-Policy query modifiers All (and) and ExactlyOne (or) demonstrate the current expressivity for the query component of the WS-Policy language. Examining both XML and RDF query languages, we see options for re-using an existing query language. In XML two declarative languages are used for matching data, XSLT and XQuery. Both of these rely on XPath for expressivity of AND and OR.
The RDF Data Access Working Group's straw-man query language (BRQL) also provides an intuitive expression for these queries:
SELECT ?service
WHERE { ?service constrainedBy ?policy .
?policy constrainedBy ?assertion .
?assertion rdf:type wsse:SecurityToken .
{ ?assertion wss:tokentype "wsse:Kerberosv5TGT" }
OR { ?assertion wss:tokentype "wsse:X509v3" } }
Tying the semantics of All and ExactlyOne to a standard query language will relieve the working group of rigorously defining these terms, as well as providing an easy conduit for implementors.
This is an RDF schema defining the basic classes (entity types) and predicates (relationships) in the WS-Policy model. This is available at http://www.w3.org/2004/08/20-ws-pol-pos/ns.
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:wsPol="http://www.w3.org/2004/08/20-ws-pol-pos/ns"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#">
<rdfs:comment>A namespace for describing a mapping for WS-Policy</rdfs:comment>
<rdfs:comment>$Revision: 1.18 $ $Date: 2004/10/12 00:48:37 $</rdfs:comment>
<rdfs:seeAlso rdf:resource="http://www-106.ibm.com/developerworks/library/ws-polfram/"/>
<dc:title>WS-Policy Schema</dc:title>
</rdf:Description>
<!-- Policy Concepts -->
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Policy">
<rdfs:label xml:lang="en">Policy</rdfs:label>
<rdfs:comment>A policy is an informal abstraction and a term that is often used to refer to the set of information that is being expressed as policy assertions .</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
<rdfs:subclass rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Operator"/>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#PolicyAssertion">
<rdfs:label xml:lang="en">PolicyAssertion</rdfs:label>
<rdfs:comment>A policy assertion represents an individual preference, requirement, capability or other property.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#PolicyExpression">
<rdfs:label xml:lang="en">PolicyExpression</rdfs:label>
<rdfs:comment> A policy expression is an XML Infoset representation of one or more policy assertions.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#PolicySubject">
<rdfs:label xml:lang="en">PolicySubject</rdfs:label>
<rdfs:comment>A policy subject is an entity (e.g., an endpoint, object, or resource) to which a policy expression can be bound.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#PolicyAttachment">
<rdfs:label xml:lang="en">PolicyAttachment</rdfs:label>
<rdfs:comment>The mechanism for associating policy expressions with one or more subjects is referred to as policy attachment.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdfs:Class>
<!-- Operator Superclasses -->
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#OperatorOrAssertion">
<rdfs:label xml:lang="en">OperatorOrAssertion</rdfs:label>
<rdfs:comment>union of Operators and Assertions.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Assertion">
<rdfs:label xml:lang="en">Assertion</rdfs:label>
<rdfs:subclass rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#OperatorOrAssertion"/>
<rdfs:comment>An atom of policy or capability expression.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdfs:Class>
<!-- Operators -->
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Operator">
<rdfs:label xml:lang="en">Operator</rdfs:label>
<rdfs:subclass rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#OperatorOrAssertion"/>
<rdfs:comment>alternative acceptable policy assertions to be authored.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#OperatorAll">
<rdfs:label xml:lang="en">OperatorAll</rdfs:label>
<rdfs:subclass rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Operator"/>
<rdfs:comment>requires that all of its child elements be satisfied</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#OperatorExactlyOne">
<rdfs:label xml:lang="en">OperatorExactlyOne</rdfs:label>
<rdfs:subclass rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Operator"/>
<rdfs:comment>requires that exactly one of its child elements be satisfied</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#OperatorOneOrMore">
<rdfs:label xml:lang="en">OperatorOneOrMore</rdfs:label>
<rdfs:subclass rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Operator"/>
<rdfs:comment>requires that at least one of its child elements be satisfied</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdfs:Class>
<rdf:Property rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#constrainedBy">
<rdfs:label xml:lang="en">constrainedBy</rdfs:label>
<rdfs:comment>how a policy or operator is constained</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#Operator"/>
<rdfs:range rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#OperatorOrAssertion"/>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2004/08/20-ws-pol-pos/ns#usage">
<rdfs:label xml:lang="en">usage</rdfs:label>
<rdfs:comment>One of Required Rejected Optional Observed Ignored</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#OperatorOrAssertion"/>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/08/20-ws-pol-pos/ns#"/>
</rdf:Property>
</rdf:RDF>
Web service characteristics can be easily and intuitively expressed in RDF. This leans on existing specifications to solve several document merging problems, as well as providing more opportunities for data/code re-use by trivially providing a hierarchical assertion model. Policy criteria can be expressed as RDF queries over web service characterizations. This, and the opportunity to re-use other policy expressions like Creative Commons and P3P should encourage the working group to consider the RDF data model expressed in RDF/XML and queried in BRQL.