Re: [Lsid-developer] Requirement for data not to change

[Sean M. <sj...@us...>]

Hello Allyson,

> 
> We also wish to return XML from the getData() calls, and lately I've
> been worried about changes to the XSD of the XML format we're using.
> What happens if there is a new release of the XSD, which renames 
> element "foo" to element "bar"? That would change the resolving of 
> all the LSIDs whose objects contain that problem element. Would I 
> have to give all of those objects a new version, even though the 
> information contained in them hasn't changed? I am guessing the 
> answer is yes, but I would be curious to see if anyone else has had 
> experience in this area. I don't know if the specification allows 
> for LSIDs that were resolvable to later become unresolvable..., and 

The spec certainly allows this. There is no obligation to resolve and 
serve data for any (even "current") LSIDs - i.e. you can just use it as a 
name with no resolver. The only obligation is that when/if you first serve 
out data bytes for an LSID, you never ever serve out any other bytes for 
the same name. 

> in any case that doesn't seem to be a suitable answer for me. 
> However, having to allow resolution for outdated XML formats seems 
> like the only way to go - of course, the metadata method can tell 
> the programmer that they are retrieving an outdated object, and give
> them the LSID of the most recent object. 
> 
> Does that sound at all sensible?

Yes it does. Although if it were me, I might also consider serving only 
metadata for the depricated LSIDs pointing to the newer ones and would 
stop serving data bytes (just provide no data binding) for those that were 
outdated, unless there was a good reason to continue to provide the out of 
date ones too.

Kindest regards, Sean