> The question is, what do we do when we do have a data breaking schema > change, like potentially in r1.1? I suggest that we just go with > http://schemas.openehr.org/v1.1 and we can assume the old > http://schemas.openehr.org/v1 meant r1.0.x. It wasn't expected to have such > a substantial schema change until r2 but I guess that is the reality of > software.
I am also concerned about 'non-breaking' changes though - well, it depends on your definition of a breaking change - but say we add an optional element to a xml type? This doesn't break any existing data because all instances will still comply with the new schema - however, new instances will now potentially not comply with the old schema. Do we consider these breaking changes? Are we expecting to create a new namespace if we do this type of change? > Jumping ship to another style such as http://schemas.openehr.org/2009/03 > would also be reasonable, it would just mean we have to correlate release > dates with release numbers. This has one advantage in that it is possible to release new major versions of the spec _without_ updating the schema. So if v1.2 needs no schema changes over v1.1, the 1.2 released schemas can be left as http://schemas.openehr.org/2009/03 - and people won't be confused thinking that their data isn't the right 'version'. > There is an optional rm_version in the archetype_details attached to any > archetyped locatable. We currently populate this only when we specify a > template_id on the composition, which is all compositions in our > applications. We could suggest that this is required for all compositions > and make this the handle to determine what schema to use for validation. Yes, but we would also need a similar mechanims for all top-level XML artifacts (archetype instances, extracts, PARTY? etc). The other suggestion I have seen on the interwebs is to make the xsi:schemaLocation attribute compulsory in instances <Composition xsi:schemaLocation="http://schemas.openehr.org/v1 http://www.openehr.org/releases/1.0.1/its/XML-schema/Composition.xsd";> <Composition xsi:schemaLocation="http://schemas.openehr.org/v1.1 http://www.openehr.org/releases/1.1.3/its/XML-schema/Composition.xsd";> The schema checker would not actually go and 'fetch' the XSD but would be looking for known URL's to indicate the exact schema version it was released against.. http://www.openehr.org/releases/1.0.1/its/XML-schema/Composition.xsd means 1.0.1 etc So the schema namespace indicates the major structural version of the schema - and the xsi:schemaLocation gives the exact schema version that the instance was created for (even though the minor schema differences between 1.0.2 and 1.0.3 may not have any data changes). I don't know whether storing this version is any use - I guess it depends on the definition of 'breaking changes' I discussed above. Andrew
