Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Looking for an example of a name colliision
 From: "Bill de hÓra" <bill@d...> > Does anyone have an example of a collision that can only be solved, > or even best be solved with XML Namespaces? A neccessary condition > is ideal, but examples where namespace represents an optimal design > decision will do. A client has dozens of databases. Some of these were derived from the same ancestor database but moved to different geographic locations and independently maintained and augmented. The semantics and date-conventions used in commonly-named tables and fields in each database were not necessarily the same. The client wants to merge the data into a new unified database, and use XML as the interchange medium. As a first line of defense, all the different databases are allotted different namespaces, so there is no capacity in the XML system for (e.g. by a programming mistake) merely copying over data from one data: movement of data requires a change of namespace as part of an explicit mapping. So the abstract solution here is to adopt a two-level hierarchical name. Even better if the upper-name is a first-class object in the system (i.e. one that can be manipulated by its own operations not requiring string operations on the name, and which has a special status.) XML namspaces provide this. To an extent, aguments about whether namespaces are necessary for anything can miss the point as comprehensively as can arguments on whether attributes, comments, PIs and entities are necessary. Such arguments are like whether Java's inner classes or "protected" status or packages are necessary: even classes are not necessary, in the sense that the power of C with no classes is no less than the power of Java with classes, but classes provide first-class embodiments of the analysis used. That is all namespaces need to do: if namespaces can provide a syntactic reflection of some useful analytical feature they are useful for programmers as a matter of craft and prudence. Fielded names have a good history and are useful. Namespaces are just a baroque, bureaucratic kind of fielded name. That namespaces are built into XSLT, for example, is a compelling reason to use them in most cases rather than rolling your own fielded name. I think some of the comments against namespaces start from the straw man that namespaces must solve modularization problems. But that is like expecting XML to solve data interchange problems:--a syntax is a vehicle for an analysis/solution not the analysis/solution itself. The point is how to make large information systems seem like they are clear and show that they are under control: so that names suggest and reinforce the desired system-analysis to programmers. It is like my comments on quality assurance last week: using namespaces won't guarantee fewer bugs; but they can be used to make interfaces more explicit by grouping and separating names. Cheers Rick Jelliffe 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
