RE: [xml-dev] Stupid Question (was RE: [xml-dev] XML doesn't deserve its "X".)

["Dare Obasanjo" <dareo@microsoft.com>]

> -----Original Message-----
> From: Nicolas LEHUEN [mailto:nicolas.lehuen@ubicco.com] 
> Sent: Wednesday, March 06, 2002 8:01 AM
> To: 'Thomas B. Passin'; 'xml-dev@lists.xml.org'
> Subject: RE: [xml-dev] Stupid Question (was RE: [xml-dev] XML 
> doesn't deserve its "X".)
> 
> I'm not asking everything to be dynamic. I try to stay as 
> pragmatic as possible. Most people write code with static 
> assumption. Their code is statically bound to a particular 
> schema. Then the schema is extended, and the code has to be 
> modified to be bound to the new version of the schema.
> 
> To me, extensibility is about finding ways to write programs 
> so that the amount of work following a schema evolution is 
> null or as small as possible. It's not about magically 
> understanding data and processing it the way it has to be. I 
> don't think a pure dynamic approach is feasable.
> 
> I do think, however, that type inheritance and polymorphism 
> (which is equivalent to dynamic processing of data depending 
> on its type) are the kind of concepts that can be used to 
> reduce the costs of extensibility.


<snip> 

Again this is functionality that already exists in XML via the polymorphic and inheritance mechanisms in XML schema[0,1]. What I'd like to see are examples and design patterns that show how subtitution groups and abstract types can be used to build polymorphic apps that adapt well to schema evolution. 

> 
> I don't want the data to describe how it can be processed ! 
> I'm not crazy enough to hope that this can be easily done...
> 
> I just want the schema to describe itself relatevily to 
> another already known schema, and dynamically provide 
> compatibility rules to legacy application, so that they can 
> read data in extended schemata as if they were in the former 
> schema, or forbid any usage of the document if it would be 
> harmful. Those compatibility rules could be expressed in 
> various ways, from views (à la AF), transformations, or a 
> type system with inheritance and polymorphism, I don't know 
> which is the best. What I notice however is that OOP provides 
> solutions for extensibility, so that it may be interesting to 
> have a close look at extensibility patterns in OOP before 
> trying to solve the problem in XML.
> 

Actually the solutions for extensibility that have been much touted for OOP aren't inheritance (which in most knowledgeable corners is derided as overused and a bad tool) but the use of interfaces and object composition/aggregation. I'm curious as to how you think these can be applied to XML. 
 

[0] http://www.w3.org/TR/xmlschema-0/#SubsGroups
[1] http://www.w3.org/TR/xmlschema-0/#abstract

-- 
THINGS TO DO IF I BECOME AN EVIL OVERLORD #230
I will not procrastinate regarding any ritual granting immortality.