You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Tobias Berlinger <tb...@web.de> on 2003/02/13 00:11:12 UTC
implementing new storage strategy for large documents?
hi,
we are working with xindice (cvs) since 6 months. in our situation we handle medium documents with deep structures.
now we have to decide to split the documents and use the collections for building parts of the hirarchy. the disadvantage in this way is that xpath and xupdate don't work over collections.
large documents are not supported by xindice. in my opinion implementing a new storage strategy for xindice would not be very helpfull. if i could work with very large documents, why use collections?
the other way is to support xpath and xupdate and indexing against the collection tree. ok this sounds crazy but why not?
any comments please :-))
regards tobias
______________________________________________________________________________
Schon wieder Viren-Alarm? Bei WEB.DE FreeMail ist das kein Problem,
hier ist der Virencheck inklusive! http://freemail.web.de/features/?mc=021158
Re: implementing new storage strategy for large documents?
Posted by se teague <te...@email.unc.edu>.
This is really interesting! I emailed the list a few weeks ago - I'm in
the graduate school of Info Science at UNC and am building a prototype
for a Xindice database interface (either in Swing or just on the web for
ease of prototype presentation). Perhaps at some point we could merge
some ideas :)
Good stuff,
Susan
Lixin Meng wrote:
>We have just built another Xindice browser might be in-line with the hope of
>treating the entire database as a big document, although it doesn't
>implement any new storage strategy.
>
>The difference of this browser from existing browsers is more data-centric
>(therefore the whole database is a big tree) rather than document-centric
>which cares more about collection and document names. Since Xindice itself
>doesn't provide enough information, the browser distill and maintain the
>schema from the database. If the schema doesn't change much, it doesn't
>require to refresh it every time.
>
>The URL to get to the browser is as follow:
>
> http://www.brownpot.com/sw_profile.html
>
>By the way, it is a open source.
>
>Regards,
>Lixin
>
>-----Original Message-----
>From: Kimbro Staken [mailto:kstaken@xmldatabases.org]
>Sent: Wednesday, February 12, 2003 3:38 PM
>To: xindice-dev@xml.apache.org
>Subject: Re: implementing new storage strategy for large documents?
>
>
>
>On Wednesday, February 12, 2003, at 04:11 PM, Tobias Berlinger wrote:
>
>
>
>>hi,
>>
>>we are working with xindice (cvs) since 6 months. in our situation we
>>handle medium documents with deep structures.
>>
>>now we have to decide to split the documents and use the collections
>>for building parts of the hirarchy. the disadvantage in this way is
>>that xpath and xupdate don't work over collections.
>>
>>large documents are not supported by xindice. in my opinion
>>implementing a new storage strategy for xindice would not be very
>>helpfull. if i could work with very large documents, why use
>>collections?
>>
>>
>
>Personally I'd love to see collections become unnecessary. The database
>model is much cleaner if you can treat the entire database as a large
>document with the ability to index and manipulate any portion of the
>document. I doubt collections will go away though.
>
>
>
>>the other way is to support xpath and xupdate and indexing against the
>>collection tree. ok this sounds crazy but why not?
>>
>>
>
>Cost of maintaining indexes is the main problem, but regardless this is
>something that should be possible to do.
>
>
>
>>any comments please :-))
>>
>>regards tobias
>>_______________________________________________________________________
>>_______
>>Schon wieder Viren-Alarm? Bei WEB.DE FreeMail ist das kein Problem,
>>hier ist der Virencheck inklusive!
>>http://freemail.web.de/features/?mc=021158
>>
>>
>>
>>
>Kimbro Staken
>Java and XML Software, Consulting and Writing
>http://www.xmldatabases.org/
>Apache Xindice native XML database http://xml.apache.org/xindice
>XML:DB Initiative http://www.xmldb.org
>
>
>
RE: implementing new storage strategy for large documents?
Posted by Lixin Meng <lx...@yahoo.com>.
We have just built another Xindice browser might be in-line with the hope of
treating the entire database as a big document, although it doesn't
implement any new storage strategy.
The difference of this browser from existing browsers is more data-centric
(therefore the whole database is a big tree) rather than document-centric
which cares more about collection and document names. Since Xindice itself
doesn't provide enough information, the browser distill and maintain the
schema from the database. If the schema doesn't change much, it doesn't
require to refresh it every time.
The URL to get to the browser is as follow:
http://www.brownpot.com/sw_profile.html
By the way, it is a open source.
Regards,
Lixin
-----Original Message-----
From: Kimbro Staken [mailto:kstaken@xmldatabases.org]
Sent: Wednesday, February 12, 2003 3:38 PM
To: xindice-dev@xml.apache.org
Subject: Re: implementing new storage strategy for large documents?
On Wednesday, February 12, 2003, at 04:11 PM, Tobias Berlinger wrote:
> hi,
>
> we are working with xindice (cvs) since 6 months. in our situation we
> handle medium documents with deep structures.
>
> now we have to decide to split the documents and use the collections
> for building parts of the hirarchy. the disadvantage in this way is
> that xpath and xupdate don't work over collections.
>
> large documents are not supported by xindice. in my opinion
> implementing a new storage strategy for xindice would not be very
> helpfull. if i could work with very large documents, why use
> collections?
Personally I'd love to see collections become unnecessary. The database
model is much cleaner if you can treat the entire database as a large
document with the ability to index and manipulate any portion of the
document. I doubt collections will go away though.
>
> the other way is to support xpath and xupdate and indexing against the
> collection tree. ok this sounds crazy but why not?
Cost of maintaining indexes is the main problem, but regardless this is
something that should be possible to do.
>
> any comments please :-))
>
> regards tobias
> _______________________________________________________________________
> _______
> Schon wieder Viren-Alarm? Bei WEB.DE FreeMail ist das kein Problem,
> hier ist der Virencheck inklusive!
> http://freemail.web.de/features/?mc=021158
>
>
Kimbro Staken
Java and XML Software, Consulting and Writing
http://www.xmldatabases.org/
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org
RE: implementing new storage strategy for large documents?
Posted by Lixin Meng <lx...@yahoo.com>.
We have just built another Xindice browser might be in-line with the hope of
treating the entire database as a big document, although it doesn't
implement any new storage strategy.
The difference of this browser from existing browsers is more data-centric
(therefore the whole database is a big tree) rather than document-centric
which cares more about collection and document names. Since Xindice itself
doesn't provide enough information, the browser distill and maintain the
schema from the database. If the schema doesn't change much, it doesn't
require to refresh it every time.
The URL to get to the browser is as follow:
http://www.brownpot.com/sw_profile.html
By the way, it is a open source.
Regards,
Lixin
-----Original Message-----
From: Kimbro Staken [mailto:kstaken@xmldatabases.org]
Sent: Wednesday, February 12, 2003 3:38 PM
To: xindice-dev@xml.apache.org
Subject: Re: implementing new storage strategy for large documents?
On Wednesday, February 12, 2003, at 04:11 PM, Tobias Berlinger wrote:
> hi,
>
> we are working with xindice (cvs) since 6 months. in our situation we
> handle medium documents with deep structures.
>
> now we have to decide to split the documents and use the collections
> for building parts of the hirarchy. the disadvantage in this way is
> that xpath and xupdate don't work over collections.
>
> large documents are not supported by xindice. in my opinion
> implementing a new storage strategy for xindice would not be very
> helpfull. if i could work with very large documents, why use
> collections?
Personally I'd love to see collections become unnecessary. The database
model is much cleaner if you can treat the entire database as a large
document with the ability to index and manipulate any portion of the
document. I doubt collections will go away though.
>
> the other way is to support xpath and xupdate and indexing against the
> collection tree. ok this sounds crazy but why not?
Cost of maintaining indexes is the main problem, but regardless this is
something that should be possible to do.
>
> any comments please :-))
>
> regards tobias
> _______________________________________________________________________
> _______
> Schon wieder Viren-Alarm? Bei WEB.DE FreeMail ist das kein Problem,
> hier ist der Virencheck inklusive!
> http://freemail.web.de/features/?mc=021158
>
>
Kimbro Staken
Java and XML Software, Consulting and Writing
http://www.xmldatabases.org/
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org
Re: implementing new storage strategy for large documents?
Posted by Kimbro Staken <ks...@xmldatabases.org>.
On Wednesday, February 12, 2003, at 04:11 PM, Tobias Berlinger wrote:
> hi,
>
> we are working with xindice (cvs) since 6 months. in our situation we
> handle medium documents with deep structures.
>
> now we have to decide to split the documents and use the collections
> for building parts of the hirarchy. the disadvantage in this way is
> that xpath and xupdate don't work over collections.
>
> large documents are not supported by xindice. in my opinion
> implementing a new storage strategy for xindice would not be very
> helpfull. if i could work with very large documents, why use
> collections?
Personally I'd love to see collections become unnecessary. The database
model is much cleaner if you can treat the entire database as a large
document with the ability to index and manipulate any portion of the
document. I doubt collections will go away though.
>
> the other way is to support xpath and xupdate and indexing against the
> collection tree. ok this sounds crazy but why not?
Cost of maintaining indexes is the main problem, but regardless this is
something that should be possible to do.
>
> any comments please :-))
>
> regards tobias
> _______________________________________________________________________
> _______
> Schon wieder Viren-Alarm? Bei WEB.DE FreeMail ist das kein Problem,
> hier ist der Virencheck inklusive!
> http://freemail.web.de/features/?mc=021158
>
>
Kimbro Staken
Java and XML Software, Consulting and Writing
http://www.xmldatabases.org/
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org