On Friday, January 11, 2002, at 11:39 AM, Dare Obasanjo wrote:
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 */ }
You're right in many cases that won't make sense, that doesn't have to be the case though. The resource instance could easily know where it came from and in theory could also know how to store it self back where it came from when modified. It doesn't work that way right now and I don't know it it should or not, but it would be consistent and would actually be very powerful.
For this reason I suggest dissasociating the results of XPath queries from
resources.
What did you have in mind?
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
theOn 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 feelbadconcept of making ResourceSets the return value of XPath queries is alists.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 nodereturn
Let's try a relational database analogy...
* Having queries return ResourceSets is like having all SQL queriesreturnWHOLE 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 queriesWHOLE 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:xapi-dev- [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/ ----------------------------------------------------------------------
Kimbro Staken XML Database Software, Consulting and Writing http://www.xmldatabases.org/
---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------