[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggested guidelines for using local types. (was Re: Enlightenmentvia
- From: "Soumitra Sengupta, Ph.D." <email@example.com>
- To: Rick Jelliffe <firstname.lastname@example.org>
- Date: Thu, 30 Aug 2001 22:12:43 -0500
Rick Jelliffe wrote:
I have followed this discussion for some time. Refrained from piping in because
I do not have a clear answer to the questions posed.\. I think (not sure
yet) that I have come to the conclusion that it is impossible to achieve
the robustness to extensibility that all of us desire.
Aarggh. The point of the example is when we start off with a schema in which all
names are known to have global or local types: we can for these make
for the local case and then
for the global case.
But when someone adds a new local name, bang, it causes the fragility problem.
The new local name is matched by the global template. The fact that I can go and
add some code (whether I do so by using ifs or longer paths is irrevelent) and make
fix things up. The issue is robustness in the face of change.
I have always thought that the X in XML was extensibility: we can extend existing document types and if our processing software has been written correctly, our loosely-coupled clients will continue to work correctly. XS even gives us the nice restriction and extension mechanism to help us if we want to make sure that when we change something any processing scripts (not relying on position-from-the-
We can choose to restrict the use of locally ambiguous names like in databases,
where a table can not have 2 columns with the same label. Which would mean
IMHO, extensibility preserved with some restrictions. It is a bit redundant
given the context is already there, but will certainly make the code robust
to the extensibility of schema. I can see some unworkable scenarios like
buyer_officer_name and seller_officer_name. It is not hard to imagine how
this can become unwieldy.
On the other hand, it almost seems inconceivable that we can come up with
a solution that would remove fragility of code forever. What happens if
we choose to invent a new type? Is it possible that we would have to rewrite
code to account for this change?
I think we are ignoring the fact that over time, definitions would change.
A label that is unique today may not be unique tomorrow and code will have
to be rewritten to account for that.
It is only in context (and the context includes the time as well) that we understand labels, don't we?