XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: Caution using XML Schema backward- or forward-compatibilityas a versioning strategy for data exchange

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, 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@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


  



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS