Abstract

This documents an RDF model for WSDL and discusses some of the architectural aspects of performing the translation.

Status

This is a very rough document and represents consensus from only a few people.

Model

The goal for the model was to represent the data in a WSDL file in a way that would be natural to understand and query in RDF. An RDF model with assertions like document --hasElement-> WSDL:Definitions, WSDL:Definitions --hasAttribute-> name is less compelling than one with assertions like srvc:EndorsementSearch --rdf:type-> wsdl:Definition. To that end, I did more than interpret the DOM tree of the wsdl file, I attempted to suss out the uthor's intent. In the process, I may have grossly misintrepreted the intent. Please correct me if this is so.

Example 1 - Snowboard.wsdl

This service description is a translitaration of Uche Ogbuji's example service description. The version for this example has the namespaces changed. This file was passed to an RDF parser which had a WSDL grammer stored in a perl data structure. This command:

algae -sClassRDFXML -a" \
(slurp '((../test/snowboard.wsdl)) \
 ask '((?p ?s ?o)) collect '())" > snowboard.rdf

generated an RDF file upon which "typical"

(namespace '(rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#
             wsdl http://schemas.xmlsoap.org/wsdl/
             wssoap http://schemas.xmlsoap.org/wsdl/soap/)
 ask '(http://www.w3.org/2001/03/19-annotated-RDF-WSDL.rdf
       (rdf:type ?service wsdl:service)
       (wsdl:hasPort ?service ?port)
       (wsdl:binding ?port ?binding)
       (wssoap:style ?binding wssoap:document)
       (wsdl:name ?binding ?bindingName))
 collect '(?port ?bindingName))

service queries could be run. (Note, this is only one query language; others are documented in a a query paper.) A picture of the above graph was generated with the command:

algae -sClassdot -a" \
(slurp '((../test/snowboard.wsdl)) \
 ask '((?p ?s ?o)) collect '())" | dot -Tjpeg -o snowboard.jpg

Example 2 - Calc.wsdl

The Calc description advertises three bindins, SOAP, HTTP POST, and HTTP GET (see the RDF description or the graphical representation. Thanks to Martin Gudgin who produced the WSDL in Visual Studio (I think). For a more managable view, see the POST, GET, and SOAP subgraphs.

Design Decisions

The basic structure of a service having a port having a binding having a portType seemed to follow from WSDL 1.1. There were several other chioces that were not so clear.

Transport Opacity

The goal with regard to transport was to see what functionality could be achieved without any knowlegdge of how transport worked. This promotes the notion of orthogonal transports. A model client here would be a device that can locate a service without understanding any of the elements in the transport namespace and pass this data to another agent or dispatch it generically to a user-supplied transport handler.

Schema Opacity

Again, an agent that peers into the schema only as far as is necessary to pass structure information to the transport handler may look as far as the xsd elements pass the nested DOM structure on.

Node Identification

WSDL and XML schema both use names within the document in a context-sensitive way. For instance, a port and an operation may both be called "GetEndorsingBoarder" but the service's port parameter specifies the port while the portType's operation parameter sepecifies the operation. RDF takes the web ideal of using URIs as unique identifiers as a given so it was necessary to add type information the the node names. The "GetEndorsingBoarder" operation was resolved against the service namespace concatenated with "absract_" while the port had "port_" added to it.

In general, I believe web architecture is furthured by having named elements treated as XML IDs and hope this restriction is added in later work.

ToDo

demonstrate joins against other RDF data: The power of RDF as a data expression language is revealed when data from previously separate applications are joined together in a query. For instance, it is trivial to join a service description against an RDF-based access control system or CC/PP-defined document transformation proxies.
pick a grammer: The WSDL grammer uses a data structure to describe what happens when a particular element or unknown element is started or ended, as well as what to do with encountered CDATA. It makes sense to use a standar schema language. This is non-trivial as the same langauge is used to process RDF/XML which has no predictable elements, but instead needs to change production rules for each level of nesting (roughly alternating between typedNode and propertyElt). This may be possible anyways, not sure.
pick a grammer RDF-API language: The WSDL grammer uses an arbitrary (though minimal) language to make RDF database API calls. It may be reasonable to express these calls in a declarative language or ontology, or perhaps pick a more universal procedural language like java byte code.
finish migration URI References for WSDL constructs: Started, see graphical representation of a sample WSDL1.2 document.