[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML-enabled databases, XQuery APIs

• To: xml-dev@l...
• Subject: Re: XML-enabled databases, XQuery APIs
• From: David Lyon <david.lyon@c...>
• Date: Sat, 16 Apr 2005 08:58:46 -0400
• In-reply-to: <15725CF6AFE2F34DB8A5B4770B7334EE07206E3B@h...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE07206E3B@h...>
• User-agent: KMail/1.7.1

On Fri, 15 Apr 2005 12:15 pm, Bullard, Claude L (Len) wrote:
> I don't understand this nearly well enough.   In a
> relational database, what are the characteristics
> of an "XML type"?

Don't you mean "XML Document Type"? If so that is the
equivilent to the <?DOCTYPE Invoice> tag.

Except that when you store the document in the database
you rip out the doctype, and store it in one of the header
fields.

So that you can query saying something like:

 select 
  *
 from 
 trader_documents 
 where 
 (document_type="Invoice")

Makes it more convenient and organised that way.

David

>
> len
>
> From: Ronald Bourret [mailto:rpbourret@r...]
>
> Ken North wrote:
> > Developers wanted more, of course, such as being able to describe
> > document structure and shred documents (map document content to columns).
> > That's
>
> also
>
> > been available for years with SQL platforms such as Microsoft SQL Server,
> > Oracle, Sybase and DB2 (XML Extender).
>
> Shredding is very useful for storing certain classes of data-centric
> documents, especially when non-XML documents need to access that data.
> In fact, I'd bet that shredding accounts for the vast majority of XML
> use with relational databases.
>
> However, shredding shouldn't be viewed as a substitute for native XML
> data storage as it doesn't preserve sibling order, comments, processing
> instructions, etc. and usually doesn't support mixed content. It also
> requires design-time mapping of the XML schema to the relational schema
> -- something that won't work with schemaless documents. So it shouldn't
> be viewed as a substitute for native XML storage but as a complementary
> technology.
>
> > Even more desirable is implementing XML as an SQL type. This provides
> > efficiencies for the SQL engine and query optimizer. Informix was the
>
> first to
>
> > demonstrate that at XML conferences in 1999. Those demos showed the XML
>
> type
>
> > gave significantly better performance than XML stored in a CLOB column.
> > (IBM acquired Informix in 2001).
>
> Interesting. Did the Informix technology ever get released?
>
> > The SQL standard has evolved to reflect the realities of the marketplace
>
> by
>
> > adding SQL/XML and an XML type. As for XQuery, we can expect support in
>
> the SQL
>
> > standard and Java (JSR-222).
> >
> > Does anyone know of an effort to publish an XQuery API for other
>
> languages?
>
> The XML:DB API is (was?) written in IDL, but (a) I don't know if anybody
> ever implemented it in anything other than Java and (b) the XQuery
> support is not yet finalized.
>
> I'm sure that individual native XML databases have XQuery APIs in other
> languages, but I'm not aware that any are trying to push them as standards.
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>

-- 
Computergrid : The ones with the most connections win.

• Follow-Ups:
  • Re: XML-enabled databases, XQuery APIs
    • From: Robert Koberg <rob@k...>

• References:
  • RE: XML-enabled databases, XQuery APIs
    • From: "Bullard, Claude L (Len)" <len.bullard@i...>

• Prev by Date: Re: test
• Next by Date: xml schema best practices question.. one big xml or lots of littlecomponents?
• Previous by thread: Re: XML-enabled databases, XQuery APIs
• Next by thread: Re: XML-enabled databases, XQuery APIs
• Index(es):
  • Date
  • Thread