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:of----- 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 pointTaminoview_ when "addResource" on an integer doesn't make sense? Do you really
mean this?
Considering that a number of native XML databases store BLOBS includingCLOBs)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 regularI don't see why it should be unreasonable to expect an API that expects tobeused 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: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/ ----------------------------------------------------------------------
