Re: Problems With Implementing XMLDB API
- Original Message - From: "Kimbro Staken" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 14, 2002 9:11 PM Subject: Re: Problems With Implementing XMLDB API > 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. I reread my original email and I find nothing disrespectful in it besides a statement that I believe the design is flawed. Where I come from, when a document that is a draft and is in the "request for comments" phase as the XML:DB API supposedly is from the notices on the page[0] then it is expected that it contains flaws which should be addressed before the document becomes enters featre freeze on its way to becoming a standard. If the word "flaw" offended anybody involved in writing the document then I extend my apologies since my intent was not to engender any hurt feelings but instead to provide a critique of the API from an implementor's(somewhat :) perspective. The issue is not important enough to me to become a spirit of ill will on this list so I've decided to retract my criticisms. [0] http://www.xmldb.org/xapi/xapi-draft.html -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #123 If I decide to hold a contest of skill open to the general public, contestants will be required to remove their hooded cloaks and shave their beards before entering. _ 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 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, wha
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
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
- 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
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
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. > > > > >
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: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
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
- 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
> >
> > 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 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/
--
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
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
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.
--
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: Friday, January 11, 2002 2:25 PM
Subject: Re: Problems With Implementing XMLDB API
> 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.
>
> There is no reason that a "Resource" need be equated with a "Document", so I
> disagree with the point about this being too 'coarse grained'.
>
> But you bring up a good point that the result set of an XPath query need not
> always be XML.
>
> A solution to this issue might be to define a 'simple type' Resource (this
> is along the lines of how the DOM defines nodes with a type flag) e.g.
> something like the interface
>
> 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.
>
> When an XPath query returns a ResourceSet, one could inspect each of the
> resources to see whether they are an XMLResource, BinaryResource, or
> SimpleTypeResource.
>
>
> 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
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.
There is no reason that a "Resource" need be equated with a "Document", so I
disagree with the point about this being too 'coarse grained'.
But you bring up a good point that the result set of an XPath query need not
always be XML.
A solution to this issue might be to define a 'simple type' Resource (this
is along the lines of how the DOM defines nodes with a type flag) e.g.
something like the interface
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.
When an XPath query returns a ResourceSet, one could inspect each of the
resources to see whether they are an XMLResource, BinaryResource, or
SimpleTypeResource.
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
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
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
Re: Problems With Implementing XMLDB API
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
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 GmbHhttp://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/ --
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
- 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 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/ --
