OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Schema Evolution

[ Lists Home | Date Index | Thread Index ]


You missed object-oriented programming, and in fact there is a whole 
line of research dealing with extensibility.

There are also elegant results. For instance, Matthias Zenger's thesis ( 
http://zenger.org ) deals with extensible components. He has a system 
that allows behaviours of components to be altered even if you do not 
have access to the source code.

The first problem I see with pure Schema evolution is not that it is not 
extensible in general, but the extensibility you get is not enough.

If your types are not defined using all groups, then 
derivation-by-extension and substitution groups can get you some 
extensibility. Also adding namespaces with version information seems to 
be a solution (there was a thread about this recently on xmlschema-dev).

The second problem is, if one doesn't want to change a schema, but one 
wants to change meaning - that is one wants to modify the behaviour of 
programs that deal with the data. I think this is beyond the possible 
not only for XML, but for any generic data representation, because you 
need to talk about programs, components and redefinition/reconfiguration 
for that.



Ronald Bourret wrote:

> Agreed.
> This is at the top of the frequently asked questions I get about XML. 
> The fact that nobody has come up with a simple and elegant solution 
> leads me to believe that there isn't one, as does the fact that nobody 
> has solved this in non-XML fields (database schemas, APIs, operating 
> systems, etc.) either.
> -- Ron
> Ian Graham wrote:
>> My own experience, on a large enterprise Web services project, is 
>> that elegant schema / WSDL evolution is not possible. There is simply 
>> no way to constrain the schema changes such that all existing 
>> applications are guaranteed to work with the new versions. So we will 
>> create new services (and keep the old) if anything needs to change.  
>> We hope that governance will help limit/control this revving process.
>> The situation is likely similar for other environments -- if you want 
>> to guarantee that all previous apps dependent on the schema work, 
>> then you can't change it.
>> If you think a schema change is idiot proof, you likely just haven't 
>> found a suitably qualified idiot :-(


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS