[auscope-geosciml] RE : changing schema in subversion tag [SEC=UNCLASSIFIED]
Eric.Boisvert at RNCan-NRCan.gc.ca
Wed Aug 11 19:19:35 EDT 2010
+1 as well
> going to cause major problems for any people currently doing testing?
if it's just changing the path, it's not too much of a problem.
De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Oliver.Raymond at ga.gov.au
Date: mer. 2010-08-11 18:56
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] changing schema in subversion tag [SEC=UNCLASSIFIED]
+1 for all Bruce's comments.
I shall copy the tags to branches, and make the necessary global changes to absolute path names.
But before I do, is moving the tag to branch (and changing the absolute path names in the schemas) going to cause major problems for any people currently doing testing?
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: Thursday, 12 August 2010 8:26 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] changing schema in subversion tag
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 --------------
A non-text attachment was scrubbed...
Name: not available
Size: 14109 bytes
Desc: not available
More information about the GeoSciML