[auscope-geosciml] changing schema in subversion tag

Simon.Cox at csiro.au Simon.Cox at csiro.au
Thu Aug 12 01:38:35 EDT 2010


But make sure not to confuse a VCS with a publication system.
Generally you should not use paths to a SVN location in anything persistent.
Persistent refs should be to the publication location.

________________________________
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: 12 August 2010 00:26
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:
https://www.seegrid.csiro.au/subversion/GeoSciML/branches/3.0_gml3.2_schemas and
https://www.seegrid.csiro.au/subversion/GeoSciML/branches/3.0_gml3.1_schemas
.
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.

Cheers
Bruce

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


To

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

cc



Subject

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 :

https://www.seegrid.csiro.au/subversion/GeoSciML/branches/3.0_gml3.2_schemas and
https://www.seegrid.csiro.au/subversion/GeoSciML/branches/3.0_gml3.1_schemas

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

https://www.seegrid.csiro.au/subversion/GeoSciML/tags/3.0.0_rc1_gml3.2_schemas and
https://www.seegrid.csiro.au/subversion/GeoSciML/tags/3.0.0_rc1_gml3.2_schemas

https://www.seegrid.csiro.au/subversion/GeoSciML/tags/3.0.0_rc2_gml3.2_schemas and
https://www.seegrid.csiro.au/subversion/GeoSciML/tags/3.0.0_rc2_gml3.2_schemas

https://www.seegrid.csiro.au/subversion/GeoSciML/tags/3.0.0_rc3_gml3.2_schemas and
https://www.seegrid.csiro.au/subversion/GeoSciML/tags/3.0.0_rc3_gml3.2_schemas

etc.

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.

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

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


More information about the GeoSciML mailing list