W3C home > Mailing lists > Public > public-web-http-desc@w3.org > June 2005

Re: Caveats for Web-friendly service description

From: Jan Algermissen <jalgermissen@topicmapping.com>
Date: Wed, 1 Jun 2005 21:41:28 +0200
Message-Id: <B014191F-770B-495F-9F9C-96370B74DBAC@topicmapping.com>
To: public-web-http-desc@w3.org


some feedback regarding Mark's posting:

I see two purposes of a description langauge: Generating code and  
keeping documentation
about services. Especially in an IT service management or software  
portfolio management
context, such documentation is key anyhow. If it is standardized, so  
much the better.

IMHO, code generation only makes sense for the service implementation  
while consumers
should only implement MIME type semantics (and not knowledge about  
the service's state
machine which is discovered at runtime in the Web's application model).

Regarding the question *what* should be described, I think that Web  
services are simply
RESTful applications[1] and that these can be described as a state  
machine, where each
state definition is a pattern or predicate (expressed in terms of a  
common data model[2])
and each allowed transition is a combination of HTTP method and a  
definition of what may
be sent as a message body (aka form) and optionally what role  
(expressed as a group URI)
may perform that transition.

As an example, consider a trouble ticket: in the DL I could state  
that for all states of
the ticket (expressed as an RDF graph) that 'match'

      the-ticket-uri tts:status 'new'

there is an allowed transition

      the-ticket-uri tts:status 'open'

I can imagine generating all the backend code (except the data  
storage of course) and
the UI portions (if desired) from such descriptions.


[1] see here for my favorite definition of the term:

[2] RDF or XML or Topic Maps (though not directly suitable in Web  
context due to
     their duality of URI semantics)

Jan Algermissen, Consultant & Programmer                              
Tugboat Consulting, 'Applying Web technology to enterprise IT'        
Received on Wednesday, 1 June 2005 19:41:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:47:19 UTC