[
Lists Home |
Date Index |
Thread Index
]
Ronald,
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.
cheers,
Burak
http://lamp.epfl.ch/~buraq
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 :-(
>
>
|
