[auscope-geosciml] Opportunities for re-factoring GeoSciML?[SEC=UNCLASSIFIED]

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Mon Jun 13 13:12:53 EDT 2011


It depends if there is a strong requirement to have that version of the schema before Edinburgh meeting for testing.  Honestly, I just started to work on instance documents so I don't have a large backlog to deal with.  Changes to the schema at this point (and if I understand correctly) is mostly rework the schemaLocation, namespaces (and prefixes) of the same instance documents and not a change to the model itself so it's not a moving target as far as the model is concerned.  In short, if the work on RC3 schemas instance is meant to provide input for final version in Edinburgh and those instance are about the same model (minus the packaging artefacts), I don't see it as a big problem (exclusing the fact that we will punish those who made their instances / services early and reward procrastinators like me) - we can still use those instance has a way to test the model.  On the other hand, if this actually changes a significant part of the model that was meant to be tested and the schema are delayed up to the eleventh hour.. I think it's too late.  If we count repackaging, and generating / testing schemas involving 2 persons 13 time zones apart, we are looking probably at one week before the schemas are ready.
 
 
BTW. is there a plan to put into place a formal RC (request change) mechanism à la OGC or is this question to be lumped into a bigger discussion about having GeoSciML as a formal OGC DWG ?
 
Eric
 
 
________________________________

De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Oliver.Raymond at ga.gov.au
Envoyé : 13 juin 2011 09:46
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] Opportunities for re-factoring GeoSciML?[SEC=UNCLASSIFIED]


There are a couple of mutual dependency glitches to iron out before Simon's suggestion could be done:
 
1. GeoSciMLCore-GeologicEvent <-> GeologicStructure-DisplacementValue = mutual dependency between GeoSciML-Core and GeologicStructure
 
2. (GeologicStructure-GeologicStructure -> GeoSciML-Core-GeologicFeature) + (GeoSciMLCore-GeologicEvent -> GeologicStructure-DisplacementValue) = mutual dependency between GeoSciML-Core and GeologicStructure
 
Apart from the above dependency glitches which would need remodelling, we are a long way down the track of version 3 now.  I'm currently putting the finishing touches to the v3 rc3 schemas and was hoping that this RC would be the last one.  A refactor at this stage (with 3 new app schemas and namespaces) would be a pretty major reconstruction of what we've been working on with v3 RC's to date (and Francois and I will effectively discard our last week's work on generating/checking the v3 rc3 schemas if we want to refactor GeoSciML now).
 
I would love to say "Put this off until version 4".  However, I am loathe to give anyone a further chance to label GeoSciML as a "moving target" with yet another refactoring at version 4.  So if we want to do any more package refactoring, I would strongly urge that we do it now or not at all.  If the GeoSciML team is amenable to Simon's refactoring suggestions, Francois and I would stop work on the current v3 rc3 schemas and we'll generate a new set of schemas after the model is refactored.
 
Given the implications of Simon's suggestion, could I ask for comments from all of the GeoSciML team with some urgency.  My personal feeling is one of ambivalence to further splitting up of the GeoSciML-Core application schema.  I'm not convinced of the need for it, but I would not be opposed to the idea if the majority of the GeoSciML community was for it.
 
Cheers,
Ollie
 
_______________________________________________________________________

Ollie Raymond

Project Leader
National Geological Maps and Data Standards Project
Geoscience Australia

Interoperability Working 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 624799917 |  Email: oliver.raymond at ga.gov.au
_______________________________________________________________________

--- 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 Simon.Cox at csiro.au
Sent: Monday, 13 June 2011 4:51 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] Opportunities for re-factoring GeoSciML?



GeoSciMLers: 

 

Following the recent changes to the model relating to relations and derivations, I'd like to ask if this opens up (again) the opportunity for some package refactoring? 

E.g. 

i . make GeoSciML-core just contain the GeologicFeature, GeologicRelation and GeologicAge leaf packages (this makes sense as geology is a historical science) and 

ii, iii, iv., move GeologicMaterial, GeologicUnit and GeologicStructure,  into their own Application Schemas. 

 

DefiningStructure and BoundaryRelationship should be moved in GeologicStructure, but otherwise I think the dependencies are pretty clean now. 

 

Simon

 

 

 

 

 

Simon Cox | Research Scientist
CSIRO Earth Science and Resource Engineering 
ARRC, PO Box 1130, Bentley WA 6102, Australia 
Tel +61 8 6436 8639 | Mob +61 403 302 672
Email simon.cox at csiro.au <mailto:simon.cox at csiro.au>  | Web http://www.csiro.au <http://www.csiro.au/> 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110613/6a693e9e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3627 bytes
Desc: image001.gif
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110613/6a693e9e/attachment.gif>


More information about the GeoSciML mailing list