Even though internally a relational database sees items returned from a query
as just another table, this isn't the same model that exists in XML especially
under the XPath model. In SQL one can do ad-hoc queries and joins from the
results of various queries and treating them as tables ensures thus, on the
other hand things like that aren't possible in XML (under XPath and under
XQuery objects are fine grained).

I think tying the type of query results to the same abstraction that is used
for items in the database is an inappropriate attempt to add consistency where
difference would be preferrable. For instance even if the API was redesigned
and XPathResultResource or something similar was added, this object would not
be able to be used in the same manner as other Resources. For example,

    String xpath = "count(/movie/title='Gladiator')";

  XPathQueryService service =
     (XPathQueryService) collection.getService("XPathQueryService", "1.0");

   ResourceSet resultSet = service.query(xpath);

ResourceIterator results = resultSet.getIterator();

while (results.hasMoreResources()) {
   XPathResultResource resource =
      (XPathResultResource) results.nextResource();

 myCollection.addResource(resource);   /* THIS MAKES NO SENSE */
}

For this reason I suggest dissasociating the results of XPath queries from
resources.

NOTE: I do realize that it is possible to create a subinterface of XMLResource
and have all XPath query results have the ability to convert themselves to XML
but that seems like a hack to save a flawed design than a good solution.

--
THINGS TO DO IF I BECOME AN EVIL OVERLORD #44
I will only employ bounty hunters who work for money. Those who work for the
pleasure of the hunt tend to do dumb things like even the odds to give the
other guy a sporting chance.
-
---- Original Message -----
From: "Lars Martin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 11, 2002 1:32 AM
Subject: Re: Problems With Implementing XMLDB API


> On Fri, 11 Jan 2002 02:16:46 -0700
> Kimbro Staken <[EMAIL PROTECTED]> wrote:
>
> >
> > On Thursday, January 10, 2002, at 11:04 PM, Dare Obasanjo wrote:
> > >
> > >
> > > From the point of view of an implementor the XPathService returns
> > > Resources
> > > within ResourceSets and this is way too coarse grained. In fact I feel
the
> > > concept of making ResourceSets the return value of XPath queries is a
bad
> > > idea
> > > for a few reasons
> > >
> > > 1.) It is inconsistent with standard XPath.
> > > 2.) It is confusing to novice developers.
> > > 3.) Very rarely is a user simply interested in just the documents that
> > > match
> > > the query but in the actual nodes even for queries that return node
lists.
> > >
> > > Let's try a relational database analogy...
> > >
> > > * Having queries return ResourceSets is like having all SQL queries
return
> > > WHOLE tables and not rows or computed values.
> > >
> >
> > No, I think you're misunderstanding what resources are. They're an
> > abstraction for any database content, be it a document, a blob, or a node
> > someplace within a document.
>
>
> And this is exactly how SQL encapsulates the possible return types
> of a SQL query.
>
>
> > The only problem area is on retrieving atomic
> > values like the value of an attribute and that is only a problem because
> > of XPathQueryService returning XMLResources by default. An atomic value is
> > not XML An atomic value would have to be some other type of resource.
> >
> > If you execute a query that looks something like
> > /some/path/to/a/[EMAIL PROTECTED] then the resource set of results should only
> > contain the value of the selected nodes not the entire document. If the
> > query returns a node set then each node from the node set is returned as
> > an individual resource. Try this with Xindice or the ref. impl and you'll
> > see that it works as you want. What won't work is trying to select
> > /some/path/to/a/node/@blah, that would return an atomic value like a
> > string or a number. That is the issue that needs to be resolved, the rest
> > already works as you expect.
> >
> > > OK, how about an OODBMS analogy,
> > >
> > > * Having queries return ResourceSets is like having all SQL queries
return
> > > WHOLE class instances and not fields or computed values.
> > >
> > > I think, however you slice it there needs to be a seperate class of
> > > objects
> > > returned by querys that are not as strongly related to Resources.
> --
> ______________________________________________________________________
> Lars Martin                             mailto:[EMAIL PROTECTED]
> SMB GmbH                                        http://www.smb-tec.com
>
> ----------------------------------------------------------------------
> Post a message:         mailto:[EMAIL PROTECTED]
> Unsubscribe:            mailto:[EMAIL PROTECTED]
> Contact administrator:  mailto:[EMAIL PROTECTED]
> Read archived messages: http://archive.xmldb.org/
> ----------------------------------------------------------------------


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

----------------------------------------------------------------------
Post a message:         mailto:[EMAIL PROTECTED]
Unsubscribe:            mailto:[EMAIL PROTECTED]
Contact administrator:  mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
----------------------------------------------------------------------

Reply via email to