[auscope-geosciml] changing schema in subversion tag

Bruce.Simons at dpi.vic.gov.au Bruce.Simons at dpi.vic.gov.au
Wed Aug 11 18:25:55 EDT 2010

I wholeheartedly support Marcus' suggestions for the two branches:

I think the 'tags' are an unnecessary overhead until we have a stable 
GeoSciML v3.0 (ie after Testbed 4 has ironed out the problems) as we don't 
expect anyone to use v3.0 until after it has been signed off.

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555 
Mobile: +61 429 177155

"Sen, Marcus A" <mase at bgs.ac.uk> 
Sent by: auscope-geosciml-bounces at lists.arcs.org.au
11/08/2010 06:00 PM
Please respond to
auscope-geosciml at lists.arcs.org.au

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

Re: [auscope-geosciml] changing schema in subversion tag

> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-
> geosciml-bounces at lists.arcs.org.au] On Behalf Of Stephen M Richard
> Sent: 10 August 2010 23:36

> in subversion?  I thought the idea of the tag directory was that things
> are locked once they get tagged (broken or not...). Probably we
Yes, I thought about bringing this up but, as we don't have a system in 
place and I need to set up services pointing to some schemaLocation before 
the end of next week I decided to play fast and loose with the rules to 
apply fixes which I needed for working services. Sorry :-)

Our situation is a bit different from the usual program development 
projects where there is source code from which the program can be 
automatically built by a build system. We have the UML source (in XMI 
format) and a semi-automatic process to build XML Schema files and we want 
versions of the generated XML Schema files to be available on the web for 
testing with instance documents and services. In addition we have two 
different XML Schema versions generated from the same UML model; one GML 
3.1 compatible and one GML 3.2 compatible.

The UML model is split into different packages which potentially can be 
versioned separately (and clearly are with the externally governed ones) 
but we are generating a single overall version of the XML Schemas using 
particular versions of each package.

There are still some ongoing fixes to the model occurring. There are also 
manual fixes to the generated XML Schema's which need making after 
generation. Keeping these in sync is currently a manual job (essentially 
down to Olly) which can't currently be done perfectly but just on a 
best-efforts basis.

Testbed participants need reference XML Schemas against which to test 
validation of their instances whether manually generated or by services. I 
would suggest that for each of the GML 3.1 and GML 3.2 versions of the 
schemas we want a location where the latest corrections will always be 
applied and periodically frozen tag versions which will not change. This 
will enable instance generators to access the current latest version for 
testing but also to choose to validate against certain fixed release 
points without worrying that the XML Schemas will change while they are 
constructing the documents. If they see a later tagged release they can 
update to point to that when they are ready for the possibility of having 
to change the instances again.

Bearing the above in mind I would like to suggest the following 
organisation as the least disruptive and easiest to implement in our 
current Testbed timescale. Rome participants can discuss any longer term 
re-organisation of the repository during that meeting.

Keep two latest GeoSciML 3.0 XML Schema only branches at :


These branches will be updated with changes from the UML model on a best 
efforts basis by Olly and with fixes to the XML Schema serialisation by 
anyone who spots them, but after consultation on the email list first if 
they are not obvious.
Periodically make frozen tag versions of the above branches at





The exact form of the names is a suggestion only.

I guess it's mainly down to Olly to say if he is happy to maintain things 
this way but comments from those creating instances would also be useful.


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

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/20100812/5c3588c9/attachment.htm>

More information about the GeoSciML mailing list