OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggested guidelines for using local types. (was Re: Enlightenmentvia

Rick Jelliffe wrote:

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-
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.

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?