[
Lists Home |
Date Index |
Thread Index
]
[Nicolas LEHUEN]
> Like you said, there is very little that the PSVI can add that the
> application doesn't. Right. But you just suppose that the data received by
> an application is in the very precise format it was built for. Now, to
come
> back to Eric's sample, if I want to add some new nifty tags to my
documents,
> so that a new part of the application can use it while old parts still
> remain compatible, I have to find a way to convey some meta-data that make
> the old parts not only understand that the new document can still be
> processed, but how to build an old-style view of it.
>
Two things seem to be perennially mixed up together in this kind of
discussion. There are two extremes when you think about how schemas might
be used. First, the schema can be used statically ahead of time, that is,
when you design your code. This is the case in play when people talk about
the code knowing the datatypes and therefore not needing PSVI information at
runtime.
The second case is the purely dynamic case, whereby nothing is known
beforehand and everything has to be deduced about the document while it is
being processed. When you knew that the document was entirely text, the DTD
usually served for this. Most HTML processing is the first case.
In real life, applications fall inbetween, though I suspect that most tend
towards the static case.
> Extensibility is not about being able to change something in a document
> structure, then modify all code that rely on this structure. It is about
> finding a way to tell an heterogeneous mix of code that a single data item
> can be viewed and processed in a way that fits it.
Again, two things have been mixed together. One whether your existing
processing will break if a document suddenly sprouts new elements and
attrbutes. Usually it won't, or the code can be arranged so it won't
because new elements and attributes can just be ignored.
Another is whether the xml (the data) can say how it is supposed to be
processed:
>It is about being able to
> mix some new code that uses the new document structure with some old code
> that use the old document structure.
>
At face value, this seems to ask that a document say how (parts of ) it
should be processed, perhaps with the help of a schema. That's a tall
order. I think the best that could be done in most cases is for a document
to point to some other document that would contain some description of the
intended processing. If the data language (like XML) supported doing that,
it certainly could be said to be "extensible", and I think that such could
be done in XML (to the extent, anyway, that you can describe process by
data).
So I don't see the issue of processing after a change to the design as being
any instrinsic barrier to extensibility. 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.
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.
For example, a well-designed hierarchical database is generally faster than
a relational database if the data's processing is well known and the data
structure remains unchanged. One challenge with using markup is to figure
out how to get the benefits of hierarchical processing AND the advantages of
a data-centric approach. This can't be done using purely procedural
thinking.
Too much rambling...
Cheers,
Tom P
|
