I think you are making a strikingly nice "rosetta stone" in some ways. You're helping sort out confusion, definitely, and I do risk working against that by adding to confusion but... I hope not. I think people should (and probably do) understand it when you name some technology, like "Schematron" or "DTD" as two things at once: both a practical definition (here's the pretty reliable technology available for use today) and as an abstraction (stuff "like this" fills a particular conceptual role in the overall flow of data and computation). I didn't quite see that that is the effect of what you are writing until you responded to me as you did, so thank you. It's a nice bright-lines picture you're drawing and I still do wonder how some of the stuff from modern programming language type theory can be sketched in, at least to convey the concepts. But, I'm out of ideas for that personally, for the moment, so.... Regards, -t Costello, Roger L. wrote: 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, thewebservice must specify three things: (1) Syntax of the data that the web service makes available toclients;use a grammar-based language such as XML Schemas, or RELAX NG, orDTD.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,orRDF/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@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php |