RE: [xml-dev] RE: Caution using XML Schema backward- or forward-compatib

["Costello, Roger L." <costello@mitre.org>]

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@emf.net] 
Sent: Saturday, December 29, 2007 9:30 PM
To: Costello, Roger L.
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] 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