[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

  • From: "Soumitra Sengupta, Ph.D." <soumitra@b...>
  • To: Rick Jelliffe <ricko@a...>
  • Date: Thu, 30 Aug 2001 22:12:43 -0500

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

Rick Jelliffe wrote:
007f01c131bf$fd43ad30$4bc8a8c0@A...">


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
match="x:person/x:name"
for the local case and then
match="x:name"
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?

Regards,

Soumitra

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.