[Auscope-geosciml] Fixing the v2.1 schemas - release of v2.2? [SEC=UNCLASSIFIED]

Rob.Atkinson at csiro.au Rob.Atkinson at csiro.au
Tue Aug 3 23:29:40 EDT 2010


Those versions were for a data product, not a schema :)

If the change is a fix, without change of the model, I'd make it a sub minor release.  If it's a evolution of the model, that shouldn't break any existing valid instances, 2.2

rob

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au
Sent: Wednesday, 4 August 2010 12:26 PM
To: auscope-geosciml at lists.arcs.org.au
Cc: solidground-support
Subject: Re: [Auscope-geosciml] Fixing the v2.1 schemas - release of v2.2? [SEC=UNCLASSIFIED]

Thanks Rob,

Looks like it should probably be v2.2.  The schema is being changed.

Cheers,
Ollie




________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Rob.Atkinson at csiro.au
Sent: Wednesday, 4 August 2010 9:57 AM
To: auscope-geosciml at lists.arcs.org.au
Cc: solidground-support at csiro.au
Subject: Re: [Auscope-geosciml] Fixing the v2.1 schemas - release of v2.2? [SEC=UNCLASSIFIED]

Do you have an official versioning strategy? I don't find anything on the web site, a readme in SVN root, or by Googling. I would have thought there would be a link from here:
https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/StandardsProcedure

>From the GeoFabric project :

Release Versioning
Versioning will follow a Version X.Y.Z protocol where X represents a Major Version
Release, Y represents a Minor Version Release and Z represents a Sub-Minor release.
Major Version - involves the addition or deletion of new feature classes, changes to
data scale or resolution or changes of a significant nature that require a change to the
schema. This excludes maintenance of existing data.
Minor Version - involves a minor change to the database that requires a change to
the schema, but is minor in nature e.g. an attribute field name correction.
Sub-Minor Version - involves amendments to existing data (e.g. attribute correction)
or the addition of single data entities within existing feature classes and other minor
changes. The Sub-Minor version does not involve a change to the database schema.

I would think that a bug fix would be a point release 2.1.1, a backward-compatible update to the model would be a 2.2

We are building tools to handle model versions, and attaching derived schemas to the source model versions, etc. Part of our challenge is to understand or impose business rules. In this case we'd see a major version requires updates of internal object ids, and when browsing the user should only see the latest Y.Z for each major version by default.

Let's hear your needs and suggestions.

GeoSciML 3.0.0 is loaded into the sandpit model registry for those of you with the latest release of SolidGround - you should be able to check its dependencies and download the entire model after loading the ISO profile - i.e. "casual" users (i.e. not needing to write back to the subversion repo) can skip most of the HollowWorld setup - and we'll soon bundle the ISO profile into the SolidGround Release. Haven't yet loaded the schemas attached to the models, this is still a manual process but we're hoping to have integrated FullMoon processing at some stage, as soon as we can locate some resources to sponsor it.

Rob

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au
Sent: Wednesday, 4 August 2010 8:57 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] Fixing the v2.1 schemas - release of v2.2? [SEC=UNCLASSIFIED]

So, could I have an indication from the group if we are happy to publish the v2.2 tag schemas as our production standard?

Is my proposed version numbering correct (ie, should it be v2.1.1?)  We are not really adding anything to the schema, just fixing a bug.

Cheers,
Ollie


------------------------------------------------------------------------------------
Ollie Raymond

National Advice, Maps and Data Standards Project
Geoscience Australia

GeoSciML Design Group
IUGS Commission for the Management and Application of Geoscience Information

------------------------------------------------------------------------------------

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
Ph: +61 2 62499575 | Fax: +61 2 62499992 | Email: Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au> | Google Map<http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1>
National geological maps  http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp
Geoscience Australia web services  http://www.ga.gov.au/resources/applications/ogc-wms.jsp
------------------------------------------------------------------------------------

 --- This message was created with 100% recycled electrons ---

________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Bruce.Simons at dpi.vic.gov.au
Sent: Monday, 2 August 2010 10:04 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] GeoSciML 2.1 ShearDisplacementStructure problem [SEC=UNCLASSIFIED]


This is not just a 1GE issue.  If GeoSciML v2.1 is to be our production standard until v3.x is released (still sometime off given we haven't tested it yet) then it needs it needs to meet not just the 1GE requirements but all the GeoSciML v2.0 use cases.  Fault, DuctileShear and FaultSystem were all included because it was felt they are required. In fact I'm a little surprised that ShearDisplacementStructure isn't an abstract class.

As such v2.1 needs to be able to deliver these classes and should be modified accordingly.  1GE can continue as is without being affected.

Cheers
Bruce

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555
Mobile: +61 429 177155
<Oliver.Raymond at ga.gov.au>
Sent by: auscope-geosciml-bounces at lists.arcs.org.au

01/08/2010 04:25 PM
Please respond to
auscope-geosciml at lists.arcs.org.au


To

<auscope-geosciml at lists.arcs.org.au>

cc



Subject

Re: [Auscope-geosciml] GeoSciML 2.1        ShearDisplacementStructure        problem [SEC=UNCLASSIFIED]










Hi Marcus,

That's OK as long as all your 1GE co-workers also realise that the v2.1 faultType attribute only works for gsml21:ShearDisplacementStructure and not Fault, DuctileShear, or FaultSystem.

Cheers,
Ollie

-----Original Message-----
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Sen, Marcus A
Sent: Friday, 30 July 2010 10:50 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] GeoSciML 2.1 ShearDisplacementStructure problem [SEC=UNCLASSIFIED]

> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-
> geosciml-bounces at lists.arcs.org.au] On Behalf Of
> Oliver.Raymond at ga.gov.au
> Sent: 29 July 2010 07:41

> John, Tim, Marcus - could you please check the v2.2 schemas for your
> 1GE purposes.  You will need them if you want to deliver Faults with
> faultType.
Our 1GE services currently return MappedFeatures with a specification of gsml21:ShearDisplacementStructure features which have a faultType property. That's the default way the 1GE connector is set up and I think everyone in 1GE will be doing it that way but BRGM can confirm. We have so little data to put in I don't think we have anything to put in the extra properties (segment?) of the Fault sub-type. Given the end of 1GE is approaching I don't suppose there's much point changing this now.

Marcus

--
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

Notice:
This email and any attachments may contain information that is personal, confidential,
legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner.

It is the responsibility of the recipient to check for and remove viruses.

If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email.

Please consider the environment before printing this email.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100804/1470ffdb/attachment.htm>


More information about the GeoSciML mailing list