Re: Enlightenment via avoiding the T-word

[Ronald Bourret <rpbourret@rpbourret.com>]

This perfectly illustrates the conundrum of whether local element
(names) are a good thing. In a database table (or Java class), column
(variable) names have local scope. If you need to reference them from
outside, you qualify them with the table (class) name. That is, Name
becomes Customer.Name.

In XML, what's the scope of a name? It's really hard to say. When you
look at the whole document, names have global scope. When you look at
individual elements, names have local scope. Both points of view are
reasonable and valid.

Furthermore, XML names aren't quite comparable to column or variable
names because there is nothing in SQL or a programming language quite
like the DOM or cut-and-paste in a text editor. That is, if I access a
column or variable, the surrounding technology forces me to be
unambiguous about the names. Nothing in XML or XML technology does this.

-- Ron

David Hunter wrote:
> 
> [Sorry for the HTML in the previous post.  Hopefully this one will be
> better.]
> 
> Yes, we do alias in our SQL queries.  In fact, we alias everything; it helps
> to break that tie between business layers and data layers.  And yes, there
> may be cases where I need to get the "name" column from the "customer"
> table, and the "name" column from the "person" table, all within the same
> query, and alias them "CustomerName" and "PersonName" respectively.  But
> this is only for the benefit of processing the data more easily.  There will
> be other processing that we need to do which doesn't need to do this.  There
> is no problem, from the database, telling which "name" is which, because
> each is in it's own table.
> 
> To me, and this analogy is in danger of getting less and less like the
> problem at hand, performing this type of query, and getting back a result
> set, would be like taking one XML document (or a couple of XML documents),
> and transforming it via XSLT to another XML document - some
> elements/attributes/etc. may get renamed, but that doesn't mean that the
> initial XML document is structured in a bad way - it just solved a different
> problem than the new one does.