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/
----------------------------------------------------------------------
