[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML Repository



Falko Braeutigam wrote:

> On Wed, 08 Dec 1999, Zvi Avraham wrote:
> > Falko Braeutigam wrote:
> >
> > [snip]
> >
> > > Here is the current Java interface pasted right out of Lars' editor ;)
> > >
> > > public interface Repository extends OzoneRemote {
> > >     public void init (String parserName)  throws Exception;
> > >     public Document getRootDocument ();
> > >     public void setRootDocument (byte[] data) throws Exception;
> > >     public Document storeDocument (byte[] data, String docName, int access) throws Exception;
> > >     public Document storeDocument (Document memDoc, String docName, int access) throws Exception;
> > >     public void linkDocument (Element from, Document to);
> > >     public Document unlinkDocument (Element from);
> > >     public NodeList xpathQuery (Document pDom);

whats this mean ? query for what ?

> > >     public NodeList xpathQuery (String qString, Document pDom);
> > >     public void addDocument (byte[] data, Element where, int access);
> > >     public void deleteDocument (Element where);
> > >     public String getParserName ();
> > >     public void setParserName (String parserName) throws Exception;
> > >     }

opps, what about renameDocument ? is it possible ?
also still didn't how I build nested documents, something like directories in filesystem ?

> >
> > I think that repository must be Virtual Filesystem, with hierarchical directories,
> > where each file can be or XML Document or BLOB (we have support for both in Ozone).
>
> Hm.. I don't know. The current design is based on the idea to use XML query
> langs (XPath for now) to search content in the database. Consider the

> following. There is one "access path" document in the database that describes
> the structure of the database. Something like:
>
> Top --- ISO
>      |
>       - DIN
>
> ISO and DIN are special XLink containers (provided by the ozone Repository
> module) that contains links to many other documents that in turn are "real" XML
> documents.

in eXcelon by defalult the XQL query includes also path to the document,
so, if for example, you looking for all authors in all documents in /TOP/DIN directory

/TOP/DIN//author

or all authors in entire XML Store:

//auhors

of course you still can implicitly specify dcoument, where query must be applied.

> To search all ISO's and DIN's we could write:
>
> NodeList nl = repository.xpathQuery ("/Top//", repository.rootDocument());
> for (int i=0; nl.getLength(); i++) {
>         Document linkedDoc = new XLink (nl.item(i).href();
>         NodeList nl2 = repository.xpathQuery (...);
>         for (int j=0; nl2.length(); j++) {
>                 doSomething (<nodes of nl2>);
>         }
> }
>
> We need only one paradigm to search any data in the repository. The first XPath
> query can be seen as filesystem access. This solution is much more flexible
> and XML'ish than a new virtual filesystem API, I think. Also, it should be no
> problem to integrate BLOBs into this architecture. All we need is a special
> XML-BLOB node much like the XLink node. Then you can mixed store XML documents,
> BLOBs and any other data you want to have in your repository. And all this
> accessible via uniform XML query technologies.
>
> What do you think?

I think that your solution is more elegant than Virtual Filesystem.
I just doubt how it will scale ? eXcelon for example have problems with large documents,
so, Virtual Filesystem solution help them to keep documents relatively small - many small PDOM documents,
instead of one big PDOM, like in Ozone XML Repository proposal.
Falko, how do you plan to solve this scalability issues ?

--
---------------------------------------
Zvi Avraham, Server Team Leader
NetManage Inc., eSupport Group