RE: Enlightenment via avoiding the T-word

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

Cut and paste is a interesting issue for XSDL.  XSDL allows one to create
not just local elements, but also anonymous complexTypes.  But XSDL also
allows for type substitution.  However, I cannot cut-and-paste the contents
of an anonymous complexType, even if it is a sub complexType of the
destination.  I, at least, consider this a whole.

Matthew

> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: Tuesday, August 28, 2001 2:03 PM
> To: Ronald Bourret; xml-dev@lists.xml.org
> Subject: RE: Enlightenment via avoiding the T-word
> 
> 
> 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>
> 
> -----------------------------------------------------------------
> 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>
>