[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Stupid Question (was RE: XML doesn't dese rveits
[Nicolas LEHUEN] 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. {me] Well, think about extending an object. Any object that knows how to talk to the parent also knows how to talk to the child, but only with the methods of the parent. Of the new methods defined for the child, and its new properties, the older objects know nothing. This is much like ignoring new elements and attributes in markup when the schema has been changed, which you were arguing against, saying it would be a bad idea or unfeasible (I didn't quote that part). [Nicolas ] [me] >So I don't see the issue of processing after a change to the >design as being >any instrinsic barrier to extensibility. It is not a barrier, it is a requirement... >It's only that the >extensibility >would be achieved in a different way from what many people are >used to. But >heck, if you want the old way, you can already serialize java >objects or >lisp code. I don't understand what you mean, here. We are asking ourselves what the 'X' in XML is for. Obviously, there is a lack of guidelines and processing models to achieve extensibility. Why should this extensibility be radically different from what we have in, say, ASN.1 (I'm not an expert, but it seems a common practice to have some "reserved" conditional blocks to provide extension points, that is to say extensions are foreseen when defining structures, they are not inserted a posteriori) ? What is the "old way" you're talking about ? Is it OOP ? [me] Procedural, which so many supposedly object systems are, too. [Nicolas] [me] >We were served well by going to more datacentric approaches in >the database >world - a relational database does not say how its tables and >data elements >are to be processed once they are retrieved. That's because >data (and its >design) is usually more stable over a long time than the >processing needs. >An example is being asked for new report types from old data. >Focusing more >on the data aspect (the markup approach) is fully in line with >this trend. >But it may be less "efficient" than using carefully crafted >procedural or >object code, when you think about any one processing run. That's an interesting point. When does data becomes code ? Is type information a piece of data, or a piece of code ? Should we fear types because they are bound to code, so they are unstable, or use them as a simple piece of meta-data ? [me] It is interesting, isn't it. Cheers, Tom P
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|