[GeoSciML] FW: Versioning

Steve Richard steve.richard at azgs.az.gov
Thu Aug 16 15:58:02 EDT 2012


FYI -- An example of what happens when your service inventory starts to
include multiple versions of feature type schema.

J

 

From: Celia Coleman [mailto:celia.coleman at azgs.az.gov] 
Sent: Thursday, August 16, 2012 11:20 AM
To: ryan.clark at azgs.az.gov; christy.caudill at azgs.az.gov
Cc: Stephen M Richard
Subject: FW: Versioning

 

Hi,

In light of having multiple service layers as new schema versions are
approved (i.e., Heat Flow), or having multiple layers with the very large
services, I thought I would ask for your input on versioning as we move
forward.  We currently have services deployed using two different versions
of the Heat Flow schema (1.9 and 1.15).  However, the most recent version,
the one approved on GDSDPWG is version 1.23.  It makes the most sense to
deploy any future services in v1.23, as it is the most complete version to
date.  However, there is a question of how to tag these services in the
arcmap project. 

 

In the past when we talked about the versioning, we decided to have multiple
layers - each one a different version, for example:

 



However, this means that the layer name (also the element name in xsd
schema) will need to always be "ThermalSpring1.8" - otherwise we will need
two schema documents; one for an un-versioned layer and one for
ThermalSprings1.8.  However, if a service is deployed using only the version
1.8, should it also be versioned?  The answer must be yes, I think.
Namespaces should reflect the most recent version, and updated.  It might
make sense to tag the older versions somewhere.  We can only have one
namespace (I think) and so maybe it makes sense to version all of the
service layers we think might change in the future, since not all will
validate against the schema doc with that namespace.  

 

Also, two different versions with the same data (ie HeaderURIs) in one
service will not know which version you are requesting.  

 

Wellheader1.5 HeaderURI:
http://resources.usgin.org/uri-gin/azgs/well/api:02-015-05016/

Wellheader1.6 HeaderURI:
http://resources.usgin.org/uri-gin/azgs/well/api:02-015-05016/

 

That means we will have to version the tokens as well as the Layer names.

 

So to summarize possible problems with multiple versioned layers per
service:

-        ElementName in the .xsd and .mxd

-        Service namespace 

-        URI rewrite rules (versioning tokens?)

-        When a new version comes out, do we automatically reopen task?

 

Another matter is the previously deployed services - should we go back and
version everything to make it uniform with newer services that will be
versioned?  It may be confusing if they are not consistently tagged.

 

Let me know your thoughts, if I have it wrong, or if I am missing anything
else.

 

Thanks,

Celia 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120816/8b796693/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2671 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120816/8b796693/attachment.png>


More information about the GeoSciML mailing list