Re: Problems With Implementing XMLDB API
On Sunday, January 13, 2002, at 04:37 AM, Dare Obasanjo wrote: Like saying goes about opinions,.everybody has one. I merely stated my opinion about the XML:DB API after the trying to implement Core Level 1 Conformance over eXcelon's DXE[0] . My last manager told me I was opinionated, over time you'll realize this too and not feel that I am trying to _dictate_ my will. There's a big difference between stating a respectful opinion and stating an disrespectful opinion. Disrespectful opinions are counter productive, they force a defensive response and thereby discourage discussion of the issue. Your opinions are presented in a disrespectful and attacking manner. Telling us that our work is flawed simply forces us to defend our work rather then to explore the issues. Drop the blatant criticism from your opinion statements and you'll find people will be much more willing to listen to what you say. This is advice from someone who has also had a discussion or two with managers about similar issues. BTW, my personal opinion on the issue is that the API is flawed, has been flawed and always will be flawed. Every design decision you make has tradeoffs, our goal here is to discuss those tradeoffs and make the best decision possible. Regardless, our decision will still be flawed, there's nothing we can do about that. I'm certainly open to the idea that there is a real problem in the API, to this point however I do not believe that there is one that can't be resolved without a fundamental design change. I think the problems lie more in faulty assumptions derived from under specification in the documentation. A problem that doesn't surprise me at all, I've always expected people to rely more on the implementations then the spec. The spec has much room for improvement. This is separate from the issue of returning atomic values from XPath queries, which is a problem that I believe can be solved within the current framework. Anyway I disagree that the return types from an XPath query should implement the Resource interface since it is a BIG assumption that the average NXD will know how to persist any return type from a query. We do not and never have assumed this. It may be implied but that is incorrect and is a point for clarification in the spec rather then a design problem in the API. APIs like XML:DB, JDBC, ODBC, etc are meant to be lowest common denominator, your suggestion is the duirect opposite of that and is instead a highest common denominator API (just like CORBA) and we know how those turn out. Here's a challenge for you. Define a lowest-common denominator set of features that will work across all current native XML databases. Can you do it? Could you have done it a year ago? For any list of features that you come up with I can guarantee that there are databases that won't support some of them. [0] I don't work for them I'm doing it for fun. -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. - Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 12, 2002 8:33 PM Subject: Re: Problems With Implementing XMLDB API Dare Obasanjo wrote: - Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 3:05 PM Subject: Re: Problems With Implementing XMLDB API Err, so addResource on a BinaryResource is OK _from an interface point of view_ when addResource on an integer doesn't make sense? Do you really mean this? Considering that a number of native XML databases store BLOBS including Tamino and eXcelon as well as the fact that a few XML-enabled databases support storing XML as blobs such as DB2 (XMLCLOB type) and Oracle (in regular CLOBs) I don't see why it should be unreasonable to expect an API that expects to be used by XML databases not to support storing binary resources. On the other hand expecting the database to expect to know how to manage floating point numbers and booleans is ludicrous in my opinion. You are always entitled to your opinion. I can understand the sentiment of not wanting to mix XML and primitive datatypes other than 'string', but this is not the way of the world. The XPath 1.0 model already deals with strings, boolean values and numbers. Moreover, the strong message we are getting from the database community is in fact that there are many people who do desire 'XML' databases to handle boolean values, numbers and dates. This project, XML:DB aims to be a standard API for XML databases. Surely we want to handle the needs of people who are designing and using XML databases. I mean, if the API is not able to serve as an acceptable mechanism for executing an XQuery or an XPath 2.0, what is the point? Just because we support XPath 1.0, does not mean that we have ever intended to _limit_ ourselves to XPath 1.0. A collection/list/set of integers is a _perfectly_
RE: Problems With Implementing XMLDB API
Hi folks This thread has got me thinking. What is returned from a query is a value. What is a legal value should be defined in the API spec. XQuery has define what a legal value is in their data model doc (see w3c data model doc). It may be wise to adopt this as a valid value in the xmldb API as well. In this light, I would use the word Value instead of Resource. cheers jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dare Obasanjo Sent: Friday, January 11, 2002 8:35 PM To: [EMAIL PROTECTED] Subject: Re: Problems With Implementing XMLDB API - Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 3:05 PM Subject: Re: Problems With Implementing XMLDB API Err, so addResource on a BinaryResource is OK _from an interface point of view_ when addResource on an integer doesn't make sense? Do you really mean this? Considering that a number of native XML databases store BLOBS including Tamino and eXcelon as well as the fact that a few XML-enabled databases support storing XML as blobs such as DB2 (XMLCLOB type) and Oracle (in regular CLOBs) I don't see why it should be unreasonable to expect an API that expects to be used by XML databases not to support storing binary resources. On the other hand expecting the database to expect to know how to manage floating point numbers and booleans is ludicrous in my opinion. A collection/list/set of integers is a _perfectly_ reasonable and well understood entity. Not for storing in a XML database. What makes this different then a collection that expects a list of XML documents each of which is valid to a particular schema, or a parent XML element into which you attempt to insert a child element that would make the XML invalid? Because those are *validation* problems as opposed to *type* problems. In both cases the database knows how to support the types but they happen to be invalid in the case of booleans and integers they are not the correct type to be handled by the database -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. _ 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/ -- -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
RE: Problems With Implementing XMLDB API
Hi Dare Have a look at the XQuery and XPath Data Model document. Both XPath2 and XQuery share the same data model as defined in the document at http://www.w3.org/TR/query-datamodel/. You are right that primitive types are the schema primitive types - all the usual suspects - float, decimal, double, datetime and about 20 others. As well, the data model supports sequences of primitive types, sequences of nodes (like nodesets)as well as a single node. A node can be a document, element, attribute, comment... At any rate, it is quite well spelled out in the aformentioned document. cheers Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dare Obasanjo Sent: Saturday, January 12, 2002 7:48 PM To: [EMAIL PROTECTED] Subject: Re: Problems With Implementing XMLDB API The valid return types from an XQuery query are XML schema types while the valid return types from an XPath 1.0 query are a boolean, string, number, or nodeset (is there one I've forgotten?). So the question is if the XML:DB API promotes the results of a query to their own type will they be XPath 1.0 types, XML schema types or some hybrid? -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. - Original Message - From: Jim Tivy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 12, 2002 4:28 PM Subject: RE: Problems With Implementing XMLDB API Hi folks This thread has got me thinking. What is returned from a query is a value. What is a legal value should be defined in the API spec. XQuery has define what a legal value is in their data model doc (see w3c data model doc). It may be wise to adopt this as a valid value in the xmldb API as well. In this light, I would use the word Value instead of Resource. cheers jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dare Obasanjo Sent: Friday, January 11, 2002 8:35 PM To: [EMAIL PROTECTED] Subject: Re: Problems With Implementing XMLDB API - Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 3:05 PM Subject: Re: Problems With Implementing XMLDB API Err, so addResource on a BinaryResource is OK _from an interface point of view_ when addResource on an integer doesn't make sense? Do you really mean this? Considering that a number of native XML databases store BLOBS including Tamino and eXcelon as well as the fact that a few XML-enabled databases support storing XML as blobs such as DB2 (XMLCLOB type) and Oracle (in regular CLOBs) I don't see why it should be unreasonable to expect an API that expects to be used by XML databases not to support storing binary resources. On the other hand expecting the database to expect to know how to manage floating point numbers and booleans is ludicrous in my opinion. A collection/list/set of integers is a _perfectly_ reasonable and well understood entity. Not for storing in a XML database. What makes this different then a collection that expects a list of XML documents each of which is valid to a particular schema, or a parent XML element into which you attempt to insert a child element that would make the XML invalid? Because those are *validation* problems as opposed to *type* problems. In both cases the database knows how to support the types but they happen to be invalid in the case of booleans and integers they are not the correct type to be handled by the database -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. _ 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/ -- -- 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
Re: Problems With Implementing XMLDB API
Jim Tivy wrote: Hi folks This thread has got me thinking. What is returned from a query is a value. What is a legal value should be defined in the API spec. XQuery has define what a legal value is in their data model doc (see w3c data model doc). It may be wise to adopt this as a valid value in the xmldb API as well. In this light, I would use the word Value instead of Resource. Exactly, the XQuery 1.0 and XPath 2.0 data models have merged. If XML:DB is really going to be the standard API for XML databases, we need to track this work. That said, what is important is what we can do with 'it' not whether 'it' is named 'Value' or 'Resource'. The current XML:DB API and Model is good. We can simply subclass the Resource class as has been intended from day 1. Jonathan -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Problems With Implementing XMLDB API
- Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 12, 2002 8:11 PM Subject: Re: Problems With Implementing XMLDB API Exactly, the XQuery 1.0 and XPath 2.0 data models have merged. If XML:DB is really going to be the standard API for XML databases, we need to track this work. That said, what is important is what we can do with 'it' not whether 'it' is named 'Value' or 'Resource'. The current XML:DB API and Model is good. We can simply subclass the Resource class as has been intended from day 1. IMHO, this is *not* the right decision. A Resource is supposed to be a type the database knows how to store/manage. The results of an XPath query are a _superset_ of the types that an XML database should know how to store. Clinging onto XPath query results = = Resource is sentimentalism and does not make for a well designed API. It is a choice that will lead to many users of the API shooting themselves in the foot and lots of exceptions at runtime (the worst kind) as people realize that not all implementors of the Resource interface are actually resources. A better solution would be to design support for XQuery/XPath 2.0 types and make sure that the types that correspond to nodes/nodesets/complexTypes implement the XMLResource interface. -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. _ 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/ --
Re: Problems With Implementing XMLDB API
Dare Obasanjo wrote: - Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 3:05 PM Subject: Re: Problems With Implementing XMLDB API Err, so addResource on a BinaryResource is OK _from an interface point of view_ when addResource on an integer doesn't make sense? Do you really mean this? Considering that a number of native XML databases store BLOBS including Tamino and eXcelon as well as the fact that a few XML-enabled databases support storing XML as blobs such as DB2 (XMLCLOB type) and Oracle (in regular CLOBs) I don't see why it should be unreasonable to expect an API that expects to be used by XML databases not to support storing binary resources. On the other hand expecting the database to expect to know how to manage floating point numbers and booleans is ludicrous in my opinion. You are always entitled to your opinion. I can understand the sentiment of not wanting to mix XML and primitive datatypes other than 'string', but this is not the way of the world. The XPath 1.0 model already deals with strings, boolean values and numbers. Moreover, the strong message we are getting from the database community is in fact that there are many people who do desire 'XML' databases to handle boolean values, numbers and dates. This project, XML:DB aims to be a standard API for XML databases. Surely we want to handle the needs of people who are designing and using XML databases. I mean, if the API is not able to serve as an acceptable mechanism for executing an XQuery or an XPath 2.0, what is the point? Just because we support XPath 1.0, does not mean that we have ever intended to _limit_ ourselves to XPath 1.0. A collection/list/set of integers is a _perfectly_ reasonable and well understood entity. Not for storing in a XML database. Again, you are entitled to your opionion. I suggest, rather than dictate what you personally think ought to be in an XML database, rather, read what others intend: http://www.w3.org/TR/query-datamodel/#sequences ... Note: Sequences replace node-sets from XPath 1.0... You may find this ludicrous, but I believe the job of XML:DB is not to dictate to the XML community what an XML database ought to contain, rather to serve the needs of this community. [snip] Because those are *validation* problems as opposed to *type* problems. Validation and type are _closely_ related concepts. Hence the term: DTD Document _Type_ Definition, what is used for classical XML validation. Jonathan -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Problems With Implementing XMLDB API
Like saying goes about opinions,.everybody has one. I merely stated my opinion about the XML:DB API after the trying to implement Core Level 1 Conformance over eXcelon's DXE[0] . My last manager told me I was opinionated, over time you'll realize this too and not feel that I am trying to _dictate_ my will. Anyway I disagree that the return types from an XPath query should implement the Resource interface since it is a BIG assumption that the average NXD will know how to persist any return type from a query. APIs like XML:DB, JDBC, ODBC, etc are meant to be lowest common denominator, your suggestion is the duirect opposite of that and is instead a highest common denominator API (just like CORBA) and we know how those turn out. [0] I don't work for them I'm doing it for fun. -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. - Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 12, 2002 8:33 PM Subject: Re: Problems With Implementing XMLDB API Dare Obasanjo wrote: - Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 3:05 PM Subject: Re: Problems With Implementing XMLDB API Err, so addResource on a BinaryResource is OK _from an interface point of view_ when addResource on an integer doesn't make sense? Do you really mean this? Considering that a number of native XML databases store BLOBS including Tamino and eXcelon as well as the fact that a few XML-enabled databases support storing XML as blobs such as DB2 (XMLCLOB type) and Oracle (in regular CLOBs) I don't see why it should be unreasonable to expect an API that expects to be used by XML databases not to support storing binary resources. On the other hand expecting the database to expect to know how to manage floating point numbers and booleans is ludicrous in my opinion. You are always entitled to your opinion. I can understand the sentiment of not wanting to mix XML and primitive datatypes other than 'string', but this is not the way of the world. The XPath 1.0 model already deals with strings, boolean values and numbers. Moreover, the strong message we are getting from the database community is in fact that there are many people who do desire 'XML' databases to handle boolean values, numbers and dates. This project, XML:DB aims to be a standard API for XML databases. Surely we want to handle the needs of people who are designing and using XML databases. I mean, if the API is not able to serve as an acceptable mechanism for executing an XQuery or an XPath 2.0, what is the point? Just because we support XPath 1.0, does not mean that we have ever intended to _limit_ ourselves to XPath 1.0. A collection/list/set of integers is a _perfectly_ reasonable and well understood entity. Not for storing in a XML database. Again, you are entitled to your opionion. I suggest, rather than dictate what you personally think ought to be in an XML database, rather, read what others intend: http://www.w3.org/TR/query-datamodel/#sequences ... Note: Sequences replace node-sets from XPath 1.0... You may find this ludicrous, but I believe the job of XML:DB is not to dictate to the XML community what an XML database ought to contain, rather to serve the needs of this community. [snip] Because those are *validation* problems as opposed to *type* problems. Validation and type are _closely_ related concepts. Hence the term: DTD Document _Type_ Definition, what is used for classical XML validation. Jonathan -- 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/ --
Re: Problems With Implementing XMLDB API
so? you also cannot store a book where SQL expects an int.
Now I'm confused.
What _good_ RDBMS API have you used that allows you to pass types that
aren't
natively supported by the DB in update operations?
Just to recap I'll rewrite
the query that Kimbro agreed didn't make sense that you are now advocating
should be a valid part of the API
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 */
}
Err, so addResource on a BinaryResource is OK _from an interface point of
view_ when addResource on an integer doesn't make sense? Do you really
mean this?
A collection/list/set of integers is a _perfectly_ reasonable and well
understood entity.
Either myCollection understands lists of integers or it doesn't. If it
understands lists of integers, then it is perfectly happy. If it doesn't
then the collection should complain that the the resource is not of the
proper _type_ to add to the collection. If you do not wish to allow the
elements of myCollection to be integers then you can _simply_ throw an
exception when you try to add the resource.
What makes this different then a collection that expects a list of XML
documents each of which is valid to a particular schema, or a parent XML
element into which you attempt to insert a child element that would make the
XML invalid?
Jonathan
--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--
Re: Problems With Implementing XMLDB API
- Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 3:05 PM Subject: Re: Problems With Implementing XMLDB API Err, so addResource on a BinaryResource is OK _from an interface point of view_ when addResource on an integer doesn't make sense? Do you really mean this? Considering that a number of native XML databases store BLOBS including Tamino and eXcelon as well as the fact that a few XML-enabled databases support storing XML as blobs such as DB2 (XMLCLOB type) and Oracle (in regular CLOBs) I don't see why it should be unreasonable to expect an API that expects to be used by XML databases not to support storing binary resources. On the other hand expecting the database to expect to know how to manage floating point numbers and booleans is ludicrous in my opinion. A collection/list/set of integers is a _perfectly_ reasonable and well understood entity. Not for storing in a XML database. What makes this different then a collection that expects a list of XML documents each of which is valid to a particular schema, or a parent XML element into which you attempt to insert a child element that would make the XML invalid? Because those are *validation* problems as opposed to *type* problems. In both cases the database knows how to support the types but they happen to be invalid in the case of booleans and integers they are not the correct type to be handled by the database -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. _ 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/ --
Re: Problems With Implementing XMLDB API
Actually rather than.
interface SimpleTypeResource extends Resource {
const STRING_TYPE = 1;
const INTEGER_TYPE = 2;
const FLOAT_TYPE = 3;
const DATE_TYPE = 4;
int getType();
String getString();
void setString();
Integer getInteger() throws cast...
Date getDate();
...
}
This interface would roughly encapsulate the XML Scheme predefined simple
types.
It would be better to do:
QName getType();
which would return {http://www.w3.org/2001/XMLSchema, string} i.e. the
actual XML Schema datatype name. Thinking on this, this method might be
properly promoted to the Resource interface itself, as XML Resources might
be referred to by the QName xsd:complexType or an actual type if the
implementation were schema aware.
The reason this is important is that XPath 2.0 and XQuery are going to be
the two most important services for XML:DB, and both are type aware.
Of course an implementation might simply return xsd:complexType for ALL
XML data and xsd:string for ALL simple data (e.g. strings, dates, numbers)
so the implementation overhead for adding this propery could be truly
negligable.
Jonathan
interface QName {
String getNamespace();
String getLocalName();
}
--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--
Re: Problems With Implementing XMLDB API
- Original Message - From: Kimbro Staken [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 8:48 AM Subject: Re: Problems With Implementing XMLDB API 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? Either a hierarchy of XPathResults objects or a single XPathResult type that has types information obtained from static types in an interface such as is done in the java.awt.Color or DOM classes. Apache Xalan actually uses both appraches http://xml.apache.org/xalan-j/apidocs/org/apache/xpath/objects/XObject.html The benefit of the hierarchy of objects is that objects of type XPathNodeSet and XPathTreeFragment can also implement the XMLResource interface and thus have the best of both worlds. A clear differentiation in the types returned by XPath queries while the ability to treat XML returned from XPath queries as resources is preserved. Thoughts? -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. -- _ 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/ --
Re: Problems With Implementing XMLDB API
On Thursday, January 10, 2002, at 06:57 PM, John Merrells wrote: It seems that somewhere along the line whoever designed the XML:DB API decided that XPath queries should return ResourceSets which seem to map to very coarse grained database objects like XML documents and BLOBs even though XPath queries can return strings, booleans, numbers and node lists. This confused me also... The API implies that the result of executing an XPath expression against a container is the list of documents that match the expression. In some cases you may want the whole document, but in others you actually want the XPath expression projected over the matching documents... With this API you'd have to take each DOM that's returned and run the XPath over that DOM to get the actual result. This only affects atomic values like the value of an attribute, not selection of document fragments. The query result Resource can encapsulate a node from anywhere in the document. Both Xindice and the reference impl work this way. John _ 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/ --
Re: Problems With Implementing XMLDB API
On Thursday, January 10, 2002, at 09:37 PM, Dare Obasanjo wrote: Hi, I'm working on implementing Core Level 0 compliance over an NXD as part of a project I'm working on and have bumped against a problem. Please use the [EMAIL PROTECTED] mailing list for discussions about the API. It seems that somewhere along the line whoever designed the XML:DB API decided that XPath queries should return ResourceSets which seem to map to very coarse grained database objects like XML documents and BLOBs even though XPath queries can return strings, booleans, numbers and node lists. Reconciling both these realities would involve a less than trivial amount of workarounds to what I think is fundamental flaw in the XML:DB API design. Is there any rationale behind ResourceSets and Resources being the most granular objects that can be returned by XPath queries? Yes, because a Resource is an abstraction for any kind of data that can be stored within the database. Right now the limitation is not in the fact that it returns resources but that it returns an XMLResource and an atomic value is not XML. This only affects XPath queries that return atomic values, node lists map into a list of resources. This is a known issue that I was hoping to address in the next revision of the API. We can discuss how on the API list. This isn't the W3C, there is no cost to participate and we could use the help. Please direct replies to the xapi-dev list only. -- 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. _ 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/ --
Re: Problems With Implementing XMLDB API
- Original Message - From: Kimbro Staken [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 10, 2002 6:06 PM Subject: Re: Problems With Implementing XMLDB API It seems that somewhere along the line whoever designed the XML:DB API decided that XPath queries should return ResourceSets which seem to map to very coarse grained database objects like XML documents and BLOBs even though XPath queries can return strings, booleans, numbers and node lists. Reconciling both these realities would involve a less than trivial amount of workarounds to what I think is fundamental flaw in the XML:DB API design. Is there any rationale behind ResourceSets and Resources being the most granular objects that can be returned by XPath queries? Yes, because a Resource is an abstraction for any kind of data that can be stored within the database. Right now the limitation is not in the fact that it returns resources but that it returns an XMLResource and an atomic value is not XML. This only affects XPath queries that return atomic values, node lists map into a list of resources. This is a known issue that I was hoping to address in the next revision of the API. We can discuss how on the API list. This isn't the W3C, there is no cost to participate and we could use the help.
Re: Problems With Implementing XMLDB API
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. 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. -- 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. -- 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. _ 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/ --
Re: Problems With Implementing XMLDB API
The problem with this approach is that you have now created a Resource that cannot be used in other situations where implementors of the Resource interface can such as storeResource(Resource res) Stores the provided resource into the database. in the Collection interface, since it makes little sense for a native XML database to know how to persist a boolean or a floating point number. so? you also cannot store a book where SQL expects an int. Jonathan -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Problems With Implementing XMLDB API
- Original Message -
From: Jonathan Borden [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 11, 2002 2:38 PM
Subject: Re: Problems With Implementing XMLDB API
so? you also cannot store a book where SQL expects an int.
Now I'm confused.
What _good_ RDBMS API have you used that allows you to pass types that aren't
natively supported by the DB in update operations? Just to recap I'll rewrite
the query that Kimbro agreed didn't make sense that you are now advocating
should be a valid part of the API
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 */
}
Please, explain to me why being able to do the above is a good thing.
--
THINGS TO DO IF I BECOME AN EVIL OVERLORD #59
I will never build a sentient computer smarter than I am.
_
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/
--
