Thanks for your comments. > 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.
That's probably the reason why I had problems with dbXML 0.6 when creating a method that completely clears a collection using listResources(). Some resources whose IDs were returned were not found by getResource(). (Wrong list, I know.) > > > 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. I'll see what I can do. I'll have a look at your test suite. There's another proposal I'd like your comments on: JDOM gets new friends every day. I've started to implement a little service that makes working with JDOM easier. You don't have to do the conversion between SAX/DOM and JDOM manually this way. The code gets cleaner. I wouln't see JDOMService as part of the API but as an optional extension, especially because it's limited to the Java world. The interface, together with a generic implementation, could be provided as a separate package. That's how it could look like: public interface JDOMService extends Service { void setValidation(boolean validation); void setContentAsJDOM(Document doc, XMLResource res) throws XMLDBException, JDOMException; Document getContentAsJDOM(XMLResource res) throws XMLDBException, JDOMException; } 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/ ----------------------------------------------------------------------