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@...]
Sent: Saturday, December 29, 2007 9:30 PM
To: Costello, Roger L.
Cc: xml-dev@...
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
_______________________________________________________________________
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@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
