Re: Enlightenment via avoiding the T-word

[Rick Jelliffe <ricko@allette.com.au>]

----- Original Message ----- 
From: "Nicolas LEHUEN" <nicolas.lehuen@ubicco.com>
To: "'Rick Jelliffe'" <ricko@allette.com.au>; <xml-dev@lists.xml.org>
Sent: Wednesday, August 29, 2001 5:44 PM
Subject: RE: Enlightenment via avoiding the T-word


> Rick wrote :
> 
> >Why is it more efficient to make the receiver of your tables 
> >disambiguate the 
> >names (by using a PSVI or XPath) than doing it when the data 
> >is serialized?
> >
> >It is nice that every table is a separate namespace. But why 
> >is there any need
> >to complicate XML with all this extra levels of processing to 
> >support that?
> 
> There is no extra level of processing. As I wrote before, in the first case
> you have XPath expressions like /stuff/person/name/text(), and in the second
> case you have /stuff/person/person-name/text().

No, you have
 <xsl:template match="x:person-name">

rather than
 <xsl:template match="/x:stuff/x:person/x:name">

or, more likely, you have
  <xsl:template match="x:name">
     <xsl:if select="parent::x:person">
         <!-- oops I need this extra test because name is reused--
        those darned people at x:: namespace keep on adding
        new local elements and our code is written to just use
        the markup. Why cannot they just use vanilla XML.... -->

In any case, if you are saying that schema-processing a document to
produce a PSVI requires no processing, I don't believe it.  Why make
work for ourselves by requiring a layer that a modicom of discipline
will obviate (is that right: are modicoms obviated?)  Obviously there 
are filesize issues for XML Schemas, and obviously there are comprehension
and overkill issues: XML Schemas pay a lot of attention to allowing 
efficient storage in objects or databases but it also introduce this name fragility 
problem. 
   
> I may be dense, but I don't think there are so many applications out there
> that care about the person-name without caring about the person itself.
> Context-independent processing may exist, but I think it is not as important
> as all the context-sensitive processing that is done out there.

See above. 

> If you want to stick with the table/column metaphor, I don't know of any
> relational data processing that care about a column without taking care of
> the table it belongs to.

But, as I have said, the table acts as a namespace. So 
  SELECT X FROM Y 
acts as
  <xsl:template match="Y:X" >
You don't have global names in that kind of DBMS per se. So 
mapping a  set of tables into the same namespace can
cause clashes.  

> When processing a document, you can hardcode the processing path followed by
> your program : "I first process the person, then the product, then the
> delivery info". 

Push programming and pull programming are both common methods with XML.

Pull programming does as you say. You process an element and
explicitly pull in specific child data as needed.

But in push programming you code each element separately: elements are processed
individually and pass information back to its parent or caller (or stream). You use your
expectation that the document has been validated as a precondition
for working on the document, which factors out the need for
lots of tests.  But if people re-use names for different types,
push programs become fragile.  A push program can be robust
in the face of new names, but if you re-use existing names then
you strongly couple the document to its specific schema and
to the generating process.  And loose coupling of distributed
processing is one of the big reasons for XML.

Cheers
Rick Jelliffe