Hi Andrew, See below. Heath
> > 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? [Heath Frankel] I understand your point here but if we cannot have some kind of schema migration mechanism we will need a new schema per release, which is something that I don't think anyone wants. Using your example, adding an optional element will cause systems that use an older schema to invalidate an instance that populates that element but at least an older system can continue to produce validate instances. I am not sure how much schema validation will be used in a production system, the overhead to validate every instance may be to great so schema validation will probably be just a testing and accreditation issue. We may need to have some parser rules a bit like HL7 V2 where you accept additional elements that you don't expect, within reason, so that we can support this forward-compatibility. This will mean that we may not be able to use auto-generated XML serialisers but there are other XML APIs that can be used to support this kind of rules. > > > 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'. [Heath Frankel] So your suggesting moving to a date oriented namespace so that there is no tie to the release number? > > > 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). [Heath Frankel] All archetyped locatables can have this and I would expect all top-level objects to be archetyped otherwise they have no domain semantics. > > 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. [Heath Frankel] I can see the utility of this, but I am not sure that we should mandate it, seems a bit of a hack.
