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

Re: need for defining standard APIs for xml storage

• From: Nikita Vinokurov <n.vinokurov@m...>
• To: gopi <gopi@a...>
• Date: Mon, 27 Mar 2000 20:25:07 +0400 (MSD)

Hi Gopinath!

Now almost all of xml storage products have a DOM interface to communicate with
the storage. Such as XDBM or Ozone-db. Or all of them try to build their API
close to the DOM one at least. I know, there is nothing in DOM spec about
Document retrieving and storing (but Nodes).  But in most cases (I was
encountered) one can create by means of xml database the model of filesystem
folders and store Documents as subtrees of folder nodes. There is lack of
features you can get by per-Document-DTD, but it provides the similarity of
namespaces. i.e. you may consider the set of documents as a big nested one.

As about optimal storing, existed xml engines store the document in accordance
with the DOM-inspired model. i.e. linked Nodes. I think there is nothing to
standardize. 

The high-level applications such as XPath or XQL are built on the top of DOM
(IMHO) so they work fine if you provide them any DOM complicant interface.


On Mon, 27 Mar 2000, gopi wrote:

> Hi all,
> 	If this is not the right mailing list to discuss about this, suggest
> exact mailing list.
> 	Right now there is no standard set of APIs defined by any
> organization on "how XML should be stored to make optimal processing". The
> XML support what we see in either MS-SQL or Oracle 8i are not useful in
> long run.  If you want to do advanced operations on xml data. They just
> retrieve the result set data in xml form and when you make any changes to
> the document, it will not be reflected in actual database (since it is just
> one way of representing result set for them). If any query is made on XML
> (using XPath or XQL or XMLQL) data already stored in db, either they won't
> support at all or they may make relational data query to retrieve result(in
> future). Once xml data is stored in relational db they lose context
> information (heirarchy information). Even if they store it in some form (in
> future), it will be inefficient when XQL query is made. The main problem is
> with "the way XML data is stored", it is not stored in native XML form
> (heirarchial form).
> 	There are some projects going on to store "native" xml document like
> in www.dbxml.org.  But if no standard APIs are defined for storing and
> retrieving XML document(DOM tree) in storage engine, it will end up with
> everyone having their own way of storing xml document.  If somebody wants
> to switch over from one database vendor(or product providing xml native
> storage)  to another, it will not be easy.  Also, it will be difficult to
> use these products as "components" with other products.  There will not any
> standard APIs to interact with any xml native storage product.  Why can't
> there be one standard set of APIs defined which every database vendor (who
> would like to support "native" xml storage) satisfy. If this happens, there
> will be efficient xml storage engines in the market and which can be
> replaced with other one if user wants.
> 	Probable advantages:
> 		1. It will be easy to integrate the parser with a xml storage
> engine. Parser implementation can use these standard APIs to store or
> retrieve information from storage. Any updates or queries can be using
> parser provided APIs also.
>		The parser can have some API like
>			parser.setStorageEngine(StorageEngine storageEngine);
> 		and interface StorageEngine is implemented by vendors.
> 		2. XSLT processor can resolve "XPath" expressions
> efficiently.  There can be "xml-caching" module and "xml-indexing" module
> interacting with "xml-storage" to do optimal data access.
> 		3. XQL processor can use "xml-caching" and "xml-indexing"
> modules to retrieve or update xml data.
> 	Requirements:
> 	1. These APIs should be generic such that the xml data can be stored
> either completely in memory or stored persistently.  Then current DOM
> implementation will become just one case of this (ie., completely in
> memory).

How do you see the mechanism of this? In case of persistance there is another
method may be added to DOM: flush() to free out memory buffer. This thing is
done in some xml storage engines.


> 	2. These APIs should be well defined so that any future APIs for
> "xml-caching" and "xml-indexing" can be defined wrt this. I hope this
> doesn't look stupid and makes sense to atleast one more person :-).
> regards, Gopinath
> 

Best Regards,

Nikita Vinokurov /Project Manager/ mailto:n.vinokurov@m...
Yagel Open Source
http://yagel.newmail.ru


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

• Prev by Date: Re: How far current XSLT processors will be useful in real applications?
• Next by Date: Re: need for defining standard APIs for xml storage
• Previous by thread: Re: XSLT transformation sheet for W3C recommendations...
• Next by thread: Re: need for defining standard APIs for xml storage
• Index(es):
  • Date
  • Thread