[
Lists Home |
Date Index |
Thread Index
]
[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
|
