[
Lists Home |
Date Index |
Thread Index
]
>
> > XML output is almost always more complex than you think at any given time.
> > I'm sure that even having written a lot of XML output code, I haven't
> > exhausted the realm of potential gotchas.
>
> That's disappointing.
>
> Developers should feel safe and comfortable generating XML with print
> statements, knowing that only < and & are special. I'm sure (as your
> article points out), it *can* be more complicated, but in most cases it
> never needs be.
>
> The problem with "just as an XML API" is that you usually have to build up
> a DOM or Infoset or some such, and then call a serialization routine.
> That's often ridiculously heavyweight for the task at hand.
I hear ya.
To be fair, my post should be leavened by the fact that peopl always have to
make trade-offs between safety and convenience. The only way to be entirely
safe is to live one's life in a cocoon. So saying "thou shalt always use an
XML API, or thou will perish" is probably a bit much. As another poster said,
the experience of the developer is a key factor in the decision.
Of course I've seen enough carelessness out there that advising people to use
an API has become my default position. It's pert self-preservation. Let me
tell you, it really bites to have to follow workflow back and forth in a
complex project to see who is spitting out he broken XML.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
XML Data Bindings in Python - http://www.xml.com/pub/a/2003/06/11/py-xml.html
Introducing Examplotron - http://www-106.ibm.com/developerworks/xml/library/x-x
mptron/
Charming Jython - http://www-106.ibm.com/developerworks/java/library/j-jython.h
tml
The commons of creativity - http://www-106.ibm.com/developerworks/xml/library/x
-think18.html
A custom-fit career in app development - http://www.adtmag.com/article.asp?id=7
744
|
