But for value-added applications, I just don't have time to implement custom
objects for every type of field I would need to store. If my organization
only uses 12 fields (reads/writes to) out of 200 possible fields, there is
no sense in having me value-subtact from the data that is on a complext
journey between complex systems. DOM provides me the ability to have an
object model, and not have to sacrifice date integrity, especially if Zope
is a middle-point between several systems needing to intercahge data. Could
I build my own object model and be able to expect better performance? Of
course, but do I have time? I've got to be a pragmitist on this one most of
the time. Caching mitigates some of the read-oriented performance concerns,
anyway. I would rather just throw more hardware at Zope (i.e. more ZEO node
boxes, more RAM & CPU speed) than have to lose this flexibility.
What would be nice is if the likelyhood of write conflicts in a
write-intensive system could be reduced by not needing to lock the whole DOM
object, but this, seems to be only a minor issue for my particular
application, so I think I'm willing to live with this as a limitaion,
becuase adding useable fields becomes simply a matter of writing an API
method (well 2 - one each for read / write), and not a whole new data
structure / class. This means that if a user of software (not a core
developer) doing this needed to extend the API on the fly with some TTW
python scripts, they could quickly and easily if they could speak DOM.
Sean
-----Original Message-----
From: Martijn Pieters [mailto:mj@zope.com]
Sent: Monday, October 22, 2001 11:27 AM
To: sean.upton@uniontrib.com
Cc: zope-xml@zope.org
Subject: Re: storing XML can be good... was Re: [Zope-xml] ANNOUNCE:
PT_XPath
On Mon, Oct 22, 2001 at 10:40:09AM -0700, sean.upton@uniontrib.com wrote:
> I hear more and more often that XML should not be stored, and just be an
> interchange format. And in most cases, that is likely to be correct,
but...
>
> I think there are some very convincing reasons to, indeed, store XML on
the
> server for particular use cases. The best possible illustration that I
can
> think of is a use case that I have; sorry that this 'manifesto for storing
> XML' is so lengthy, but I think this position needs definitive
justification
> - and I think that for this use case below, I'm right... ;)
>
> Eventually, for our internal use, my company will likely be creating a
> product that will support the use and storage of NITF (News Industry Text
> Format) and NewsML - both standards for news content defined by the IPTC
> (International Press Telecommunications Council) and/or the Newspaper
> Association of America (NAA). These DTDs were designed to address
> deficiencies in current information flow in the newspaper industry; NITF,
in
> particular, began in the pre-XML days, as an SGML DTD with the specific
goal
> of allowing news producers/vendors to scrap the 150 or so different
> proprietary text interchange and storage formats used by the industry.
The
> idea was that in translation (filtering) between lots of formats,
> information is almost always lost, and always costly.
To me, this is still no reason to justify an XML storage. Note that Zope
doesn't force you to use a fixed number of fields; the object tree and
python provide you with much more flexibility. I am convinced that it is
posible to build a Zope app with the same fidelity as the NITF, with
lossless conversion between the internal storage format and NITF.
Using Zope objects instead of XML would buy you speed and scalability. DOMs
are memory hogs, and CPU intensive to build and manipulate. Only use a DOM
when a custom API isn't feasable. Don't carry around all that extra weight
if you can avoid it!
--
Martijn Pieters
| Software Engineer mailto:mj@zope.com
| Zope Corporation http://www.zope.com/
| Creators of Zope http://www.zope.org/
---------------------------------------------
objects for every type of field I would need to store. If my organization
only uses 12 fields (reads/writes to) out of 200 possible fields, there is
no sense in having me value-subtact from the data that is on a complext
journey between complex systems. DOM provides me the ability to have an
object model, and not have to sacrifice date integrity, especially if Zope
is a middle-point between several systems needing to intercahge data. Could
I build my own object model and be able to expect better performance? Of
course, but do I have time? I've got to be a pragmitist on this one most of
the time. Caching mitigates some of the read-oriented performance concerns,
anyway. I would rather just throw more hardware at Zope (i.e. more ZEO node
boxes, more RAM & CPU speed) than have to lose this flexibility.
What would be nice is if the likelyhood of write conflicts in a
write-intensive system could be reduced by not needing to lock the whole DOM
object, but this, seems to be only a minor issue for my particular
application, so I think I'm willing to live with this as a limitaion,
becuase adding useable fields becomes simply a matter of writing an API
method (well 2 - one each for read / write), and not a whole new data
structure / class. This means that if a user of software (not a core
developer) doing this needed to extend the API on the fly with some TTW
python scripts, they could quickly and easily if they could speak DOM.
Sean
-----Original Message-----
From: Martijn Pieters [mailto:mj@zope.com]
Sent: Monday, October 22, 2001 11:27 AM
To: sean.upton@uniontrib.com
Cc: zope-xml@zope.org
Subject: Re: storing XML can be good... was Re: [Zope-xml] ANNOUNCE:
PT_XPath
On Mon, Oct 22, 2001 at 10:40:09AM -0700, sean.upton@uniontrib.com wrote:
> I hear more and more often that XML should not be stored, and just be an
> interchange format. And in most cases, that is likely to be correct,
but...
>
> I think there are some very convincing reasons to, indeed, store XML on
the
> server for particular use cases. The best possible illustration that I
can
> think of is a use case that I have; sorry that this 'manifesto for storing
> XML' is so lengthy, but I think this position needs definitive
justification
> - and I think that for this use case below, I'm right... ;)
>
> Eventually, for our internal use, my company will likely be creating a
> product that will support the use and storage of NITF (News Industry Text
> Format) and NewsML - both standards for news content defined by the IPTC
> (International Press Telecommunications Council) and/or the Newspaper
> Association of America (NAA). These DTDs were designed to address
> deficiencies in current information flow in the newspaper industry; NITF,
in
> particular, began in the pre-XML days, as an SGML DTD with the specific
goal
> of allowing news producers/vendors to scrap the 150 or so different
> proprietary text interchange and storage formats used by the industry.
The
> idea was that in translation (filtering) between lots of formats,
> information is almost always lost, and always costly.
To me, this is still no reason to justify an XML storage. Note that Zope
doesn't force you to use a fixed number of fields; the object tree and
python provide you with much more flexibility. I am convinced that it is
posible to build a Zope app with the same fidelity as the NITF, with
lossless conversion between the internal storage format and NITF.
Using Zope objects instead of XML would buy you speed and scalability. DOMs
are memory hogs, and CPU intensive to build and manipulate. Only use a DOM
when a custom API isn't feasable. Don't carry around all that extra weight
if you can avoid it!
--
Martijn Pieters
| Software Engineer mailto:mj@zope.com
| Zope Corporation http://www.zope.com/
| Creators of Zope http://www.zope.org/
---------------------------------------------