[XML-SIG] Hello

[uche.ogbuji@fourthought.com]

> Without wishing to start a "flame war", I would argue that storing your
> data in XML has little if any value... being able to represent it in XML
> which needed is much more important.  XML is from my perspective a data
> interchange format, one which easily surpases nearly all others.  It's not
> a database format, however.  Maybe I've just been scared off by all the
> hype.

It's far more than that, but your description is a start.

> Anyway, as for Zope (since I'm one of the product manager), DTML was
> never inteded to be XML + XSL/T, for a couple reasons:
> 
> 	o DTML predates XML by year and years
> 	o XSL/T is a moving target
> 	o XSL is way too burdensome for most users

Oh please.  First of all, DTML's precedence means nothing.  Would you suggest 
users go back to VSAM?  The main thing is that XML has truly global support by 
many industries.  This will be hard for any proprietary standard to top.

As for XSLT, it is frozen, and only waits final W3C approval (and the TBL 
annointment) to become a W3C rec.  There goes the "moving target" argument.  
There are several processors that support the final standard: XT, Saxon, 
LotusXSL, and, in part 4XSLT in Python.

Please explain what you mean by "burdensome".  If you mean because it is 
declarative, I'll point out that some people learn XSLT much more quickly than 
procedural programming.  Python programmers are probably not automatically 
sympathetic to declarative programming, but remember that it takes all sorts.

If you mean optimization, there is already a lot of work on this in the 
xsl-list, and I think that the theory of XSLT optimization, because driven by 
a broader community and rooted in more CS history, will progress faster than 
proprietary alternatives.

> As for the last, I put forward that if it takes myself or someone else
> I work with HOURS to figure out how to do something that we do in DTML
> trivially, then it's not as simple as it should be.  DTML provides things
> like tree representation with automatic handling of expansion/closing,
> as well as batch management.  It is a REPORTING language, not a transform
> language, there is a fundemental difference in the targets.

Exactly.  You should have said that, rather than shooting general broadsides 
at XSLT.  I would imagine an XML reporting language more as a DOM-based 
framework around XQL than XSLT.

> Having said that, we're commited to using XML where it's appropriate,
> and have some cool stuff that works with DOMs right now.  It will be
> driven by customer needs, however, rather than blind adhearance to
> standards.

Let me note that entities such as Microsoft and the old, bad IBM often 
defended their avoidance of open standards by talking disdainfully about 
"blind" adoption.  Clear statement of problems with standards and open 
discussions of improvements is more fruitful.  I'd like to hear more precise 
explanations of areas where you or the Zope community think XML is unsuitable.

Mind you, I have no argument with Zope: Zope 2.0 is very nifty.  I just want 
useful discussion of the issues with no off-hand dismissals.

-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org