RE: Removal of Texts and Compatibility

Marc,

I am very sorry that I haven't read your recent posts.  I know it's
frustrating to post some quality ideas and then not get the readership
one is hoping for.  

My posts on removal and schemas were prompted by Roger Costello's
original question of the same on xml-dev some time ago, and I've finally
had a chance to publish something a little polished.

I'm glad you like the ideas and the discussion of XML Schema.  I am
still trying to get to covering in fairly complete detail a few
different strategies for versioning using Schema, but as you know it is
quite a slog.

I do promise to look at your work as soon as I can..

Cheers,
Dave

> -----Original Message-----
> From: Marc de Graauw [mailto:marc@marcdegraauw.com] 
> Sent: Friday, September 14, 2007 5:55 AM
> To: David Orchard; 'www-tag'
> Subject: RE: Removal of Texts and Compatibility
> 
> David Orchard:
> 
> | I've just posted a couple of entries on Removal of Texts and 
> | Compatibility.  The first looks at the question from a Set 
> | perspective, and the second from an XML Schema 1.0 perspective.  I 
> | don't know whether we'll have a chance or interest to 
> discuss at the 
> | f2f but I think they are quite applicable to the TAG versioning 
> | finding.
> 
> These are important ideas. I guess you haven't read my recent 
> posts on Making Changes Compatible [1], [2], which outline 
> very similar ideas. I've got a solid use case too: in the 
> Dutch HL7-based EHR, we're effectively at version 2 (previous 
> versions weren't implemented for production) and - you'll 
> guess it - the Schema's have no wildcards nor any real 
> provisions for forward compatibility. Since we in fact do 
> expect the removal of a required element (amongst others) we 
> need a non-disruptive approach to changes. For some changes 
> we are in a n:m situation. We have a central National Hub, 
> but this Hub is not allowed to touch medical content, so can 
> only mediate for changes in non-medical content. Since the 
> nodes are all healthcare providers (from GP to hospital) the 
> number of nodes will be large, and moving to later versions 
> has to be a gradual process where Vn+1 senders don't break 
> existing receivers. So I'm excited to see your proposals, and 
> I for one do think such ideas are very relevant for the 
> Versioning Finding. In our situation, it's not just removal 
> approaches we need, but additions as well since we don't have 
> the wildcards in place, so you'll find those too in my [1] and [2]. 
> Especially your second post with the Schema's is very helpful.
> 
> Cheers,
> 
> Marc
> 
> [1]
> http://www.marcdegraauw.com/2007/09/10/making-all-changes-comp
atible-over-multiple-versions-part-1/
> [2]
> http://www.marcdegraauw.com/2007/09/11/making-all-changes-comp
atible-over-multiple-versions-part-2/
> [3] ... to be written yet ...
> 
> | http://www.pacificspirit.com/blog/2007/09/13/when_can_language
> | _components_be_removed_and_maintain_backwards_or_forwards_comp
> | atibility
> | http://www.pacificspirit.com/blog/2007/09/13/using_xml_schema_
> | 10_when_can_language_components_be_removed_and_maintain_backwa
> | rds_or_forwards_compatibility
> |  
> | Cheers,
> | Dave
> | 
> 
>

Received on Friday, 14 September 2007 17:03:22 UTC