Andrew Patterson wrote: >> CRs in this release have necessitated some very small (non-data >> affecting) changes in the schema BaseTypes.xsd (impact statement of >> Release 1.0.2 at >> http://www.openehr.org/svn/specification/BRANCHES/Release-1.0.2-candidate/publishing/release_notes_1.0.2.htm >> ; published Release 1.0.1 schemas at >> http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html) >> > > I am going through the 1.1 release candidate changes and it appears > that some of these are going to be 'breaking' changes to the > schema. So our plan for handling the 1.0.2 schema should have > an eye out to 1.1, which will need to be handled in a > somewhat compatible manner.. >
there will certainly be breaking changes in the archetype schema, which doesn't not cause a great problem as long as it is handled properly. Handling it properly means tools of the future knowing the difference between the current Archetype.xsd schema and later more efficient variants. > >> Firstly, openEHR publishes a number of schemas, not just one. Each >> carries only the release id, but not an individual version number. I >> would argue that they should carry an individual version id (and >> possibly not the Release number?). Can the XML experts here comment on >> what the usual way to manage the kind of componentised schemas we use in >> openEHR is? Should we, as of this release put a per-schema version id in >> each schema? >> > > I don't think the version id etc _inside_ the schema file is too > important - I worry a great deal about the XML instances that are out > there and how instances can be automatically matched up to their > corresponding schema files. That to me is the fundamental issue. > I would contend that 1.1 will require a change to the schema > namespace to "http://schemas.openehr.org/v1.1"; or > "http://schemas.openehr.org/v2"; or "http://schemas.openehr.org/2008/12"; > (if we decide to break > the correspondance between schema set version and openehr > release version) > ok - this approach more or less replicates the release id approach already in use, but converts it to a URL. We already have the URL pattern http://www.openehr.org/releases/N.M.P, so we could do http://www.openehr.org/releases/N.M.P/schemas Apparently it is not always expected that the URL mentioned in a schema actually exists so http://schemas.openehr.org/v1.0.2 could be used as well. Or we could create it for real. (What are the requirements here?) > I do not know how the instance versioning will work with > multiple indepedant schemas (I presume Thomas is referring > to the Template schema vs AM schema etc). I think schemas > well actually in this case I was thinking more of the RM schemas like Basic_types.xsd and the others - http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html . Starting from Composition.xsd, there is a cascade of nested inclusions down to Basic_types.xsd. If an XML document representing a Composition is to correctly indicate its schema, it should point to e.g. http://www.openehr.org/releases/1.0.2/schemas/Composition.xsd or http://schemas.openehr.org/1.0.2/Composition.xsd Inclusions are curently done with a statement like <xs:include schemaLocation="Content.xsd"/> which does not mention the version of the included schema, so one assumes it is from the same release, which is the effect we want. Is this the orthodox way to do this in XML land? - thomas
