Re: Experiences with XML:DB
Lars Martin wrote: > > On Tue, 22 May 2001 07:39:47 -0700 > Tom Bradford <[EMAIL PROTECTED]> wrote: > > > Lars Martin wrote: > > > > 2. It's not so easy to understand why Collection.getResources() returns > > > > a String[] of IDs and XPathQueryService.query() returns a > > > > ResourceIterator. In both cases it might be good to have both > > > > possibilities, first to iterate through the resources and second to get > > > > a list of resource IDs. My priority lies on the ResourceIterator. > > > > > > I came across the same. I like the Iterator pattern but I don't know > > > if it makes sense to return an iterator for each and every method. > > > > One of the reasons I can see for 'not' returning a set of IDs from a > > query is that the results may be synthetically generated, and might not > > even have IDs. Returning a set of IDs assumes that the query language > > is producing a set of results that map to actual collection resources. > > But what if I executed a query that performed an XSLT transformation or > > dynamically produced a document fragment that held the current time? > > Exactly. This is actually the way XPath works in the ref. impl as well as in the dbXML impl. There are no keys associated with the resources returned because the result of the query is a node set not a set of documents. > > > Still, I see the value in having Collection return a ResourceIterator as > > the set of IDs is likely to change, a ResourceIterator can give you a > > more up-to-date snapshot of them as you're walking the list. > > Yup, this sounds reasonable to me. What do others think? This is actually the way the Collection interface worked originally. It seems like even if you return the ResourceIterator that you would want it to be a snapshot and not be live. Otherwise you have to specify that all implementations must make it live which could be very difficult to do in some cases. Things are much simpler by just returning keys as a snapshot of the repository and leaving it up to the app to retrieve the actual resources. > > Lars > -- > __ > Lars Martinmailto:[EMAIL PROTECTED] > SMB GmbHhttp://www.smb-tec.com > > -- > Post a message: mailto:[EMAIL PROTECTED] > Unsubscribe:mailto:[EMAIL PROTECTED] > Contact adminstrator: mailto:[EMAIL PROTECTED] > Read archived messages: http://archive.xmldb.org/ > -- -- Kimbro Staken The dbXML Project http://www.dbxml.org/ -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Experiences with XML:DB
Lars Martin wrote:
>
> Hi.
>
> On Tue, 22 May 2001 15:29:21 +0200
> Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
>
> Well, on the one hand I see the advantage of this object oriented
> approach to have a common QueryService interface. On the other hand
> I would try to keep the API layer as thin as possible. Your proposal
> doesn't functionally extent the current API, you can achieve the same
> with the following - and I think that's your current solution:
>
> public interface SQLSelectQueryService extends Service {
> ResourceIterator query(String sqlQuery) throws XMLDBException;
> }
>
> public interface XPathQueryService extends Service {
> ResourceIterator query(String xpathQuery) throws XMLDBException;
> }
>
> Don't get me wrong here. I see the advantage of your example above. IMO
> the costs (i.e. complexity) outweighs the advantages here. Other ideas?
>
I think if the query interfaces become more complex with multiple shared
methods then the proposed change makes a lot of sense. I'd like to see
how things develop a little more though before we make a change.
>
> Of course you can add a "delete" method (or whatever you need) to your
> proposed SQLSelectQueryService interface - no problem so far. The Service
> interface was introduced to provide a future-proof extension mechanism.
> Today we don't know what functionality the future will provide.
>
> The XPathQueryService provides a read-only interface to XPath, therefore
> "delete()" doesn't make sense and "query()" should be the only method
> defined at this interface.
>
> So I propose - as already discussed with Kimbro - to provide a Service
> interface for the XUpdate specification. This spec provides tags to
> modify any XML document (incl. delete) and a Java based implementation
> does already exist.
Yes, I'll be introducing this for discussion in the next few days along
with the CollectionManagement service that was also discussed
previously. I'm thinking both will be optional at Core Level 0 and 1.
>
> > 4. Wouldn't it be nice to have a set of conformance tests for XML:DB so
> > we can improve exchangability between drivers and faciliate and speed up
> > the development of drivers? For the Java world this could consist of a
> > package of JUnit tests, for example.
>
> This is true. As far as I could see Kimbro already checked in a "simple"
> test suite based on JUnit. And Per Nyfelt (are you here Per? :-) started
> to implement a test suite for Ozone that could be contributed to XML:DB.
> Anyway, every kind of help is welcome and if you're interested to volunteer,
> check out the latest CVS and have a look at the sources. Again, any
> help is welcome. :-)
Yes I commited the start of a test suite along with the reference
implementation and some other classes that will make up an SDK for
developing API implementations. I haven't had time to add proper
documentation or anything yet so for now it is just available from CVS.
Getting some help in fleshing out all of this would be great.
>
> > The XML:DB API, so far, is exactly what I need. So I guess the project
> > is on the right track.
>
> Great!
> Do others have development experiences?
>
> > I'm looking forward to your comments.
> >
> > Jeremias Märki
> >
> > mailto:[EMAIL PROTECTED]
> >
> > OUTLINE AG
> > Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> > Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
> > Internet http://www.outline.ch
> --
> __
> Lars Martinmailto:[EMAIL PROTECTED]
> SMB GmbHhttp://www.smb-tec.com
>
> --
> Post a message: mailto:[EMAIL PROTECTED]
> Unsubscribe:mailto:[EMAIL PROTECTED]
> Contact adminstrator: mailto:[EMAIL PROTECTED]
> Read archived messages: http://archive.xmldb.org/
> --
--
Kimbro Staken
The dbXML Project
http://www.dbxml.org/
--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact adminstrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--
Re:
Lars Martin wrote: > > I have just downloaded v0.6 and ran the APIExample. Everything works > > fine, now what do I add/change to allow me to run this on a different > > server?? > > This seems to be a dbXML specific question, doesn't it? Anybody here > from the dbXML team? ;-) I knew this would happen at some point. I'm surprised it didn't happen sooner. For more information on joining the dbxml-core-general list, where you can post questions regarding dbXML, visit http://sourceforge.net/mail/?group_id=7824 At least it wasn't cross-posted :) -- Tom Bradford --- The dbXML Project --- http://www.dbxml.org/ We store your XML data a hell of a lot better than /dev/null -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re:
On Tue, 22 May 2001 12:29:13 -0400 "Craig Smith" <[EMAIL PROTECTED]> wrote: > I have just downloaded v0.6 and ran the APIExample. Everything works > fine, now what do I add/change to allow me to run this on a different > server?? This seems to be a dbXML specific question, doesn't it? Anybody here from the dbXML team? ;-) Lars -- __ Lars Martinmailto:[EMAIL PROTECTED] SMB GmbHhttp://www.smb-tec.com -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Experiences with XML:DB
On Tue, 22 May 2001 07:39:47 -0700 Tom Bradford <[EMAIL PROTECTED]> wrote: > Lars Martin wrote: > > > 2. It's not so easy to understand why Collection.getResources() returns > > > a String[] of IDs and XPathQueryService.query() returns a > > > ResourceIterator. In both cases it might be good to have both > > > possibilities, first to iterate through the resources and second to get > > > a list of resource IDs. My priority lies on the ResourceIterator. > > > > I came across the same. I like the Iterator pattern but I don't know > > if it makes sense to return an iterator for each and every method. > > One of the reasons I can see for 'not' returning a set of IDs from a > query is that the results may be synthetically generated, and might not > even have IDs. Returning a set of IDs assumes that the query language > is producing a set of results that map to actual collection resources. > But what if I executed a query that performed an XSLT transformation or > dynamically produced a document fragment that held the current time? Exactly. > Still, I see the value in having Collection return a ResourceIterator as > the set of IDs is likely to change, a ResourceIterator can give you a > more up-to-date snapshot of them as you're walking the list. Yup, this sounds reasonable to me. What do others think? Lars -- __ Lars Martinmailto:[EMAIL PROTECTED] SMB GmbHhttp://www.smb-tec.com -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
[no subject]
I have just downloaded v0.6 and ran the APIExample. Everything works fine, now what do I add/change to allow me to run this on a different server?? Tks Craig
Re: Experiences with XML:DB
Lars Martin wrote: > > 2. It's not so easy to understand why Collection.getResources() returns > > a String[] of IDs and XPathQueryService.query() returns a > > ResourceIterator. In both cases it might be good to have both > > possibilities, first to iterate through the resources and second to get > > a list of resource IDs. My priority lies on the ResourceIterator. > > I came across the same. I like the Iterator pattern but I don't know > if it makes sense to return an iterator for each and every method. One of the reasons I can see for 'not' returning a set of IDs from a query is that the results may be synthetically generated, and might not even have IDs. Returning a set of IDs assumes that the query language is producing a set of results that map to actual collection resources. But what if I executed a query that performed an XSLT transformation or dynamically produced a document fragment that held the current time? Still, I see the value in having Collection return a ResourceIterator as the set of IDs is likely to change, a ResourceIterator can give you a more up-to-date snapshot of them as you're walking the list. -- Tom Bradford --- The dbXML Project --- http://www.dbxml.org/ We store your XML data a hell of a lot better than /dev/null -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Experiences with XML:DB
Hi.
On Tue, 22 May 2001 15:29:21 +0200
Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Hi
>
> I'm currently implementing the XML:DB API as a layer on top of JDBC. The
> XML files are stored as blobs. Indexing is done by evaluating several
> predefined XPath statements where the results get written in to
> additional columns on the table. Currently I don't have an
> XPathQueryService but created an SQLSelectQueryService which accepts
> queries in the form of the WHERE-part of an SQL query.
>
> An example:
>
> sqlservice.query("orderid >= 123 AND orderid <= 146");
>
> as an equivalent of:
>
> xpathservice.query("//order[id >= 123 and id <= 146]");
>
>
> My experiences:
>
> 1. It would be nice to have some kind of abstract string-based query
> service so it is easier to switch query languages. I don't have XPath
> right now so I'm starting with SQL. But later I'd like to switch query
> languages. My proposal is pretty simple:
>
> public interface QueryService extends Service {
>ResourceIterator query(String query) throws XMLDBException;
> }
>
> public interface XPathQueryService extends QueryService {
> }
>
> public interface SQLSelectQueryService extends QueryService {
> }
>
> Having this I could write:
>
> String srvtype = "SQLSelectQueryService";
> String myquery = "country = 'fr'";
>
> QueryService service = (QueryService) coll.getService(srvtype, "1.0");
> ResourceIterator results = service.query(myquery);
Well, on the one hand I see the advantage of this object oriented
approach to have a common QueryService interface. On the other hand
I would try to keep the API layer as thin as possible. Your proposal
doesn't functionally extent the current API, you can achieve the same
with the following - and I think that's your current solution:
public interface SQLSelectQueryService extends Service {
ResourceIterator query(String sqlQuery) throws XMLDBException;
}
public interface XPathQueryService extends Service {
ResourceIterator query(String xpathQuery) throws XMLDBException;
}
Don't get me wrong here. I see the advantage of your example above. IMO
the costs (i.e. complexity) outweighs the advantages here. Other ideas?
> 2. It's not so easy to understand why Collection.getResources() returns
> a String[] of IDs and XPathQueryService.query() returns a
> ResourceIterator. In both cases it might be good to have both
> possibilities, first to iterate through the resources and second to get
> a list of resource IDs. My priority lies on the ResourceIterator.
I came across the same. I like the Iterator pattern but I don't know
if it makes sense to return an iterator for each and every method.
> 3. Just an idea: What about a convenience method on QueryService to
> delete resources without having to fetch them in the first place?
>
> public interface QueryService extends Service {
>ResourceIterator query(String query) throws XMLDBException;
>void delete(String query) throws XMLDBException;
> }
Of course you can add a "delete" method (or whatever you need) to your
proposed SQLSelectQueryService interface - no problem so far. The Service
interface was introduced to provide a future-proof extension mechanism.
Today we don't know what functionality the future will provide.
The XPathQueryService provides a read-only interface to XPath, therefore
"delete()" doesn't make sense and "query()" should be the only method
defined at this interface.
So I propose - as already discussed with Kimbro - to provide a Service
interface for the XUpdate specification. This spec provides tags to
modify any XML document (incl. delete) and a Java based implementation
does already exist.
> 4. Wouldn't it be nice to have a set of conformance tests for XML:DB so
> we can improve exchangability between drivers and faciliate and speed up
> the development of drivers? For the Java world this could consist of a
> package of JUnit tests, for example.
This is true. As far as I could see Kimbro already checked in a "simple"
test suite based on JUnit. And Per Nyfelt (are you here Per? :-) started
to implement a test suite for Ozone that could be contributed to XML:DB.
Anyway, every kind of help is welcome and if you're interested to volunteer,
check out the latest CVS and have a look at the sources. Again, any
help is welcome. :-)
> The XML:DB API, so far, is exactly what I need. So I guess the project
> is on the right track.
Great!
Do others have development experiences?
> I'm looking forward to your comments.
>
> Jeremias Märki
>
> mailto:[EMAIL PROTECTED]
>
> OUTLINE AG
> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
> Internet http://www.outline.ch
--
__
Lars Martinmailto:[EMAIL PROTECTED]
SMB GmbHhttp://www.smb-tec.com
--
Post a messa
Experiences with XML:DB
Hi
I'm currently implementing the XML:DB API as a layer on top of JDBC. The
XML files are stored as blobs. Indexing is done by evaluating several
predefined XPath statements where the results get written in to
additional columns on the table. Currently I don't have an
XPathQueryService but created an SQLSelectQueryService which accepts
queries in the form of the WHERE-part of an SQL query.
An example:
sqlservice.query("orderid >= 123 AND orderid <= 146");
as an equivalent of:
xpathservice.query("//order[id >= 123 and id <= 146]");
My experiences:
1. It would be nice to have some kind of abstract string-based query
service so it is easier to switch query languages. I don't have XPath
right now so I'm starting with SQL. But later I'd like to switch query
languages. My proposal is pretty simple:
public interface QueryService extends Service {
ResourceIterator query(String query) throws XMLDBException;
}
public interface XPathQueryService extends QueryService {
}
public interface SQLSelectQueryService extends QueryService {
}
Having this I could write:
String srvtype = "SQLSelectQueryService";
String myquery = "country = 'fr'";
QueryService service = (QueryService) coll.getService(srvtype, "1.0");
ResourceIterator results = service.query(myquery);
2. It's not so easy to understand why Collection.getResources() returns
a String[] of IDs and XPathQueryService.query() returns a
ResourceIterator. In both cases it might be good to have both
possibilities, first to iterate through the resources and second to get
a list of resource IDs. My priority lies on the ResourceIterator.
3. Just an idea: What about a convenience method on QueryService to
delete resources without having to fetch them in the first place?
public interface QueryService extends Service {
ResourceIterator query(String query) throws XMLDBException;
void delete(String query) throws XMLDBException;
}
4. Wouldn't it be nice to have a set of conformance tests for XML:DB so
we can improve exchangability between drivers and faciliate and speed up
the development of drivers? For the Java world this could consist of a
package of JUnit tests, for example.
The XML:DB API, so far, is exactly what I need. So I guess the project
is on the right track.
I'm looking forward to your comments.
Jeremias Märki
mailto:[EMAIL PROTECTED]
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch
--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact adminstrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--
