Hi Tom,

A colleague just sent me something that I find helpful:

A client may perform the following steps on  
the data it retrieves from a web service: 

1. Validate you get what you expect
2. Understand what you get
3. Use what you get 

A web service may make the following artifacts available to clients to
assist them with "validating that they get what they expect":

(a) A grammar-based schema for validating that the retrieved data
contains the expected tags and they are arranged in the expected order.
(b) A rule-based schema for validating that the relationships of the
data are as expected (co-constraints, cardinality constraints, and
algorithmic constraints are fulfilled). 

The technologies for these artifacts are:

(a) XML Schema, RELAX NG, DTD
(b) Schematron

[To tie this back to an earlier email, I assert that these "validation
artifacts" are one thing and a "versioning strategy" is another, and
the two should be separate.]

A web service may also make artifacts available to clients to assist
them with "understanding what they get":

(a) A document (or documents) to help clients understand the data they
retrieve

There are many technologies to achieve this, including prose (i.e.
create a web page that client developers can read), data dictionary,
RDF/S, OWL.

/Roger



-----Original Message-----
From: Thomas Lord [mailto:lord@e...] 
Sent: Saturday, December 29, 2007 9:30 PM
To: Costello, Roger L.
Cc: xml-dev@l...
Subject: Re:  RE: Caution using XML Schema backward- or
forward-compatibility as a versioning strategy for data exchange

Costello, Roger L. wrote:
  

I think that for a client to be able to utilize a web service, the
    

web
  

service must specify three things:

(1) Syntax of the data that the web service makes available to
    

clients;
  

use a grammar-based language such as XML Schemas, or RELAX NG, or
    

DTD.
  

Ok.


  

(2) Relationship constraints (e.g. co-constraints) on the data; use
Schematron.

  
    

Seems a bit arbitrary.   Why "relationship constraints" of that 
particular form?
What's your theory, here?   Your claim wasn't that Schematron can be
useful
but that "[in order] for a client to be able to utilize a web service 
[....]" which is
a remarkably strong claim.

 


  

(3) Semantics of the data; use a data dictionary, or English prose,
    

or
  

RDF/S, or OWL, some combination thereof.

  
    

Again, what's your theory?   Some notation that usefully indicates
semantics
seems a good idea, I grant you.   Obviously, also, service has to be 
documented somewhere.
How did you get from there to "English prose, RDF/S, or OWL, some
combination thereof"?


(2) and (3) suggest investments, presumably with some return.   They 
also suggest
suggestions competitive with a lot of well developed theory in program 
typing and
in modeling the semantics of programs.   So, why are the technologies 
and approaches
you suggest the right choice here?

-t



_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php