[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.
Yes - I don't want that either. I bring it up because if we are allowing
minor schema changes
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
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
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081213/9bec2dda/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
on openEHR XML-schema versioning
Andrew Patterson wrote:
ok - this approach more or less replicates the release id approach
already in use, but converts it to a URL.
Except, this is a change that occurs in all xml _instances_, not just
the schema files. So every reference model document
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081211/397539dc/attachment.html
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081210/7e1ab55e/attachment.html
7 matches
Mail list logo
