>> Except, this is a change that occurs in all xml _instances_, not just >> the schema files. So every reference model document in every >> system in existence now has to handle two different schemas >> and convert between them. We have to decide whether this is >> what we want.. do the xml schemas aggressively track the >> exact spec versions, or do we only increment xml schema >> versions when necessary (and therefore should the xml >> schemas have a separate version) > > I don't think this is the case - each document should just indicate which > schema it is derived from.
Each document does - using the namespace. There's no other 'version' information in the XML instances - we could put a mandatory 'version' element in at the root of 'composition' or something but it isn't there at the moment. There is also the possibility of using the xsi:schemaLocation within the instances as another technique. > There will always be new and improved XML-schemas > - that is just the nature of a formalism that is inherently inefficient - > people will keep coming up with ways to improve it. Any document created > from a previous version of the schema will point to the earlier version. > Since all schemas in openEHR are designed to convert into the same reference > model, the data remain interoperable (unlike purely schema-based approaches > to health data). Well yes, in an abstract sense that is true - but where the rubber meets the road so to speak, you have actual XML instances, and XSD schemas and I'm telling you as someone who does this day in and day out - changing the namespace of a schema/instances means that they will no longer validate using standard xml tools - so you now have an issue with multiple schemas and how you will handle them. I agree with you that this is a boundary problem, because eventually they convert into a standard reference model. But lets not make the mistakes like HL7 do and pretend that the actual technical artifacts are unimportant details - xml instances and schemas are the things that you give to programmers to get aquainted with the standard. And nothing will annoy them more than having no clear guidance on how the instances/schemas/specs relate to each other, or finding a document that purports to be version A but finding it not validate against schema A. > The main point it seems to me is what the schema should carry as its > namespace... is it (as today): > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; > xmlns="http://schemas.openehr.org/v1"; > targetNamespace="http://schemas.openehr.org/v1"; > elementFormDefault="qualified" version="v1.0.2" > id="BaseTypes.xsd"> This will result in instance documents that do not describe whether they conform to the 1.0.0, 1.0.1, or 1.0.2 spec > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; > xmlns="http://schemas.openehr.org/v1"; > targetNamespace="http://schemas.openehr.org/v1.0.2"; > elementFormDefault="qualified" > id="BaseTypes.xsd"> This will result in instance documents that describe exactly what version of the spec they conform to, but will result in every system needing to interoperate with as many schema files as there are minor releases of openehr. > I don't know what weight the 'version' attribute carries in the xs:schema > tag - I don't understand why there appear to be two ways of indicating the > version in fact. >From the XML schema spec: "The other attributes (id and version) are for user convenience, and this specification defines no semantics for them." > so sticking with the current style of URI is no problem. yes. Andrew
