On April 3, 2003 03:24 pm, Phil Shrimpton wrote:

> On Thursday 27 March 2003 16:11, you wrote:
>
> Hi,
>
> > I think it's an excellent question around which to
> > examine some architectural issues.
> >
> > Among the many questions to be answered are:
>
> In a different order than posted...
>
> > * Is the function well understood?
>
> XML is easy, its just text with a bit of mark up, learning Wordstar at
> school was harder. Where XML differs to 'other' formats is it is one
> standard that a lot of people seem to be adopting/adopted, especially in
> the industry I work in (Government, banks etc.). Previously every system
> had a raft of propriety interfaces and propriety formats, now they are all
> starting to use XML
>
> > The first question, of course, is whether or not a piece of functionality
> > is appropriate to embed in the server.
>
> I see two peices of funtionality
>
> - Getting XML in and out of the DB
> - Using XML within the DB (SP's, triggers etc.)

Since the first one is a given, since it's client side, could you explain the
second, how should, for example a stored procedure deal with XML? I would
think that for storing XML a BLOB or text field would be sufficient, as for
processing XML, that's different, the database is a data store, XML is a data
store, so you could add a lot of complexity to the engine trying to process
what should be separate columns within an XML column. It would make more
sense for the client to explode the XML into separate database columns and
store those, as a table. Perhaps some of the utilities could handle this,
using a standard available XML parser. This would make more sense then
trying to add a mechanism to deal with XML columns within a text column.

Paul S