RE: Enlightenment via avoiding the T-word

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

In XML, the closest we have to that reference 
scope is XPath+Name.   XML Namespaces 
interfere with that simplicity.  To 
use the closest thing XML has to a 
query (not XQuery today, ok) needing 
a qualified name, we have to keep up 
with the namespace and that isn't simple.

Cut and paste in an editor that is only 
syntax aware busts all bets.  Cut and paste 
in a property-aware editor has to automatically 
adjust the properties.  That isn't simple.

DOM is a little different.  If the namespace 
is a DOM property (an element in the DOM always
has a namespace value even if null), then 
an operation over that data has access to that 
property.  Yes?  If a local name in a DOM 
doesn't inherit the namespace of its container, 
then that isn't simple.

What less do we dare to do here?

Maybe namespaces should be avoided or simply 
treated as transient properties.  Nahh!

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Ronald Bourret [mailto: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.

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.xml.org/ob/adm.pl>