I can see some better schemes in the offing from the experts! I would not think we should change anything in the current schema approach, as this is a minor release. I propose to change only the version ids in the relevant schemas to reflect the small change in Base_types. We will leave it to a new major version (1.1 or later) to change tack on how to manage schema versions. I would suggest that XML experts here would need to develop a bullet-proof approach to this (as opposed to just suggestions), so that we can implement it in a major release.
- thomas beale Heath Frankel wrote: > 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. > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > -- *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> * *
