[auscope-geosciml] changing schema in subversion tag
Sen, Marcus A
mase at bgs.ac.uk
Wed Aug 11 04:00:22 EDT 2010
> -----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.
More information about the GeoSciML