potential changes to VODataService!
kmb at mssl.ucl.ac.uk
Thu Jun 7 07:50:50 PDT 2007
Hi Ray I cannot answer for Guy, but yes a Registry for Astrogrid does
keep local copies of the schema for validation, if there is no local
copy as long as there is a xsi:schemaLocation defined for any
new/extended schema then it will validate and store into the database.
So if a Registry has an older/today 1.0 schema and a component/client
writes XML to the new 1.0 schema filling in the optional elements then
it would be rejected because it would check the local copy.
Again I am not to concerned since 1.0 is still quite new and nobody is
really adopting it just yet and there is a good chance our registries
will need another upgrade so we could pick up the new schema if it gets
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
> 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
> 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:
> 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.
More information about the registry