Cart
[Home] [By Thread] [By Date] [Recent Entries]
With an ammendment: if one is using XML for process communication, one can want to validate the XML against a schema if there is any chance that another process can touch that file. This takes some wisdom and smarts about class and message design. The example that made me add this is the MS configuration file handler. Note we are inside a framework now, not in an very large open environment but the concept of schema as a message contract is the same. so now, irrespective of scale, we have to ask the same questions about boundaries. A fundamental value is scaling across the view dimensions, for you chaos/complexity theorists, and I guess it is the concept of the schema-as-contract. The good news is that the schema-as-test is useful at different scales but following that, not the same one, so the notion that we should fit the schema to the scope is empirically right. I wonder about that one given correct-by-construction techniques using components that have not been altered. Agghh... version control rears its ugly head again. Do I apply it to the component or to the contract or both? Can I prove it or should I just run it and wait for the exception to be thrown? This stuff must drive the framework.xml and application class designers nuts. len From: Bullard, Claude L (Len) Let's ask the question another way. Considering that a schema only knows how to do one thing, test conformance of an instance to itself, where should a schema sit in a model-view-controller architecture?
|
