potential changes to VODataService! (fwd)

[Ray Plante]

This one missed the list

---------- Forwarded message ----------
Date: Thu, 7 Jun 2007 15:49:27 +0100
From: Guy Rixon <guyrixon at gmail.com>
To: Ray Plante <rplante at ncsa.uiuc.edu>
Subject: Re: potential changes to VODataService!

Ray,

1. The software I'm writing today is the VOSI implementation I mentioned in my 
other mail to you. It's the service implementation of VOSI, so it emits 
documents rather than consuming and validating them. Later, maybe next week, I 
have to write the client which will need to validate. Today, I've been 
validating with oXygen.

2. For validating with oXygen, I rely on the schemaLocation attributes in the 
instance document and in the import statements of the various schemata. The 
tool doesn't handle relative URLs in schemaLocation, so I refer to copies of 
the schemata on http://software.astrogrid.org/schema in which all the location 
URLs are absolute. When I write the validating client I'll probably try to make 
it use the remote schemata too.

3. The service software does not use XML binding. For the client, I expect to 
use XPath and/or XSLT rather than binding.

4. The question doesn't apply to the service. For the client, I intend to make 
it accept any Capability for which a schema can be found on the web.

5. In the client, I would expect it not to crash, but it would reject the 
input.

6. It should get it dynamically.

I note that the proposed changes probably won't be noticed by the code I'm 
working on, since they don't affect Capabilities, but changes to schema make me 
nervous. A "harmless" change to a schema inside AstroGrid a while back cost us 
about a staff month of repairs.

Cheers,
Guy


On 7 Jun 2007, at 15:28, Ray Plante wrote:

> Hi Guy and Kevin,
> 
> Thanks for your comments.  Since you are among the few that have responded, 
> they carry a lot of weight.
> 
> I want probe your situations a bit more.  Below, I refer to your application. 
> For Guy, I'm refering to the software you mentioned.  For Kevin, I mean your 
> registries.  Keep in mind that the changes being proposed are such that 
> existing instance documents will still be valid.
> 
> 1.  Does your application do validation?
> 2.  Do you keep and use a copy of the schema local to your application or
>    does your application download it transparently from www.ivoa.net?
> 3.  Do you use an XML-binding tool such as JAXB?
> 4.  Do you tolerate VOResource records that invoke extensions that were
>    previously unknown to you?
> 5.  If an incoming VOResource record contained elements from a known
>    schema that you were not expecting (i.e. it looks invalid to you),
>    would your application break?    (This might occur, for example, if
>    you are using JAXB or rely on elements appearing in a particular
>    order).
> 6.  Can your application be upgraded simply by retrieving the latest
>    version of the schema, or is there more involved?
> 
> On Thu, 7 Jun 2007, KevinBenson wrote:
>> Also note I am thinking this might break one of your rules you mentioned on 
>> Nov 21 'Version Numbers on XMLSchemata' see this url: 
>> http://www.ivoa.net/forum/registry/0611/1760.htm
> 
> I assume that you are refering to rule #2.
>
>  2.  backward compatible changes that should not invalidate/break
>      existing instances or applications
> 
> These would not invalidate existing instances.  My questions above are about 
> examining the effect on your applications.
> 
> Not updating the namespace represent a low-to-middle ground of disruption. 
> When you change the namespace, either everyone is highly disrupted upgrading 
> their records and applications or no one is disrupted, because the change is 
> not adopted.  If you don't change the namespace and the syntax is 
> backward-compatible to the instance documents, then only some subset of 
> applications are affected.
> 
> thanks!
> Ray
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Guy Rixon.vcf
Type: text/directory
Size: 16315 bytes
Desc: 
URL: <http://www.ivoa.net/pipermail/registry/attachments/20070607/b548bbfe/attachment-0001.bin>
-------------- next part --------------