Jeremias Maerki wrote:
>
> 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.)
>
Yes wrong list. :-) We definitely need to hear about things like this
though. Do you consider this behavior a bug in the API it self? Is it
simply a usage problem? Or do you think it is a bug in the
implementation?
> 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.
Keeping it a seperate package would be fine especially if you had a
default impl that just worked on top of any API impl. BTW, logically
this should really be a resource not a service.
Would it be more consistent if the service simply had a method that
returned a JDOMResource.
public interface JDOMService extends Service {
void setValidation(boolean validation);
JDOMResource getResource(XMLResource res);
}
public interface JDOMResource extends Resource /* or maybe XMLResource
*/ {
void setContentAsJDOM(org.jdom.Document doc) throws XMLDBException,
JDOMException;
org.jdom.Document getContentAsJDOM() throws XMLDBException,
JDOMException;
}
>
> 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/
> ----------------------------------------------------------------------
--
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/
----------------------------------------------------------------------
