RE: Remarks about XML:DB API
But I do see it as a problem, which was the point I was trying to make with my Oracle example. Ok. Sorry, for the misconception. You and Dare are correct that Services tied exclusively to collections are not intuitive and inadequate. Understand though that until I implemented the API on Oracle I'd done two other impls. One for Xindice and the reference impl. Both of those have full hierarchies including a natural root so the problem wasn't apparent. Now it is obvious. I can imagine that you didn't see it before. I probably also wouldn't have since X-Hive also has root collection :) Anyway, if there is a problem then it has to be solved. I need to think some more about you suggestions of extending the getService mthod with a context parameter. I personaly still have bad feeling about tying services to collections but that's more about intuition than about arguments (except the one mentioned earlier), so I have to examine it some more. Arno -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Remarks about XML:DB API
On Friday, February 8, 2002, at 04:07 AM, Arno de Quaasteniet wrote: I can imagine that you didn't see it before. I probably also wouldn't have since X-Hive also has root collection :) Anyway, if there is a problem then it has to be solved. I need to think some more about you suggestions of extending the getService mthod with a context parameter. I personaly still have bad feeling about tying services to collections but that's more about intuition than about arguments (except the one mentioned earlier), so I have to examine it some more. Well as Dare pointed out that was a stupid idea, it didn't actually solve the problem at all. We're going to have to change the concepts around the Database instance to enable services at that level. I need to think about it more. Arno -- 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: Remarks about XML:DB API
On Fri, 8 Feb 2002 04:40:57 -0700 Kimbro Staken [EMAIL PROTECTED] wrote: It's widely used though, simply because dbXML, eXist and now Xindice use it. It may not be used in any big installations, but it is definitely used in a whole bunch of little ones. I don't necessarily agree that it's too late to make some significant changes though. We've never said the API is complete or stable. If the changes are really necessary and improve things then we'll consider it, though, the idea of changing names is one I'm not currently fond of. If I' d seen a large amount of confusion from users I'd feel differently, but I haven't really seen it. We've had the API in use for about a year and in that time hundreds of people have used it. I absolutely agree here. BTW, we used the API in several proto types and smaller research projects so far. I just want to add one remark at this, which is more a practical matter. At X-Hive we initially also took the approach of creating typed iterators resolving in a huge amount of iterator classes, which essentially did nothing more than casting. At a certain point we decided to drop this approach, en just use java.util.Iterator, we did this because we feeled that these Iterator interface polluted both the documentation and the source code. I wish we could do this, unfortunately the API really does need to be language independent. We could of course name things the same as Java ... yup, that's the point to pay attention! since it is the most common implementation language. Whether it's really worth doing or not I don't know. Lars. -- __ 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: Remarks about XML:DB API
On Thursday, February 7, 2002, at 02:01 PM, Tom Bradford wrote: Yes... and it shouldn't cause confusion because Services as they're implemented at the moment can't be repointed to other Collections. To a Service, the Collection provides context. It may be a starting context for recursive processing, or it may be a singular context... Depends on the nature of, and how the service is implemented. There's nothing stopping someone from implementing a Service that is tied to the root Collection of the database and operates on the database as a whole, but not allowing the possibility of context would be too restrictive contextually, where naming and implementation flexibility are concerned. The problem comes if there is no root collection. For instance I have an Oracle 9i impl where the collection hierarchy is flat. I had to synthesize a root collection in order to have a starting point to create collections. This isn't intuitive when the database doesn't support a hierarchy of collections. I actually agree with Dare on this, Services tied to collections is too limiting. We need a cleaner distinction of database level services. I don't think all services should be database level, but the concept needs to exist. -- Tom Bradford - http://www.tbradford.org Apache Xindice (Native XML Database) - http://xml.apache.org Project Labrador (Web Services Framework) - http://notdotnet.org -- 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: Remarks about XML:DB API
--- Tom Bradford [EMAIL PROTECTED] wrote: On Thursday, February 7, 2002, at 02:09 PM, Kimbro Staken wrote: The problem comes if there is no root collection. For instance I have an Oracle 9i impl where the collection hierarchy is flat. I had to synthesize a root collection in order to have a starting point to create collections. This isn't intuitive when the database doesn't support a hierarchy of collections. I actually agree with Dare on this, Services tied to collections is too limiting. We need a cleaner distinction of database level services. I don't think all services should be database level, but the concept needs to exist. My only argument is that Collection-level services are needed, and shouldn't be eliminated. I have no problem with adding Database level services. :) This can easily be supported by doing what I did with SiXDML. Just add getService(String, String) to the Database class. = LAWS OF COMPUTER PROGRAMMING, VIII Any non-trivial program contains at least one bug. http://www.25hoursaday.com Carnage4Life (slashdot/advogato/kuro5hin) __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.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: Remarks about XML:DB API
On Thursday, February 7, 2002, at 02:30 PM, Dare Obasanjo wrote: This can easily be supported by doing what I did with SiXDML. Just add getService(String, String) to the Database class. Here's the problem with that though. Imagine you have a program that performs service requests in a generic fashion against Collections that are passed to it. Now furthermore, say you have two collections, one is a collection that is relationally mapped, the other that is native. Because of this, the Service may have to be implemented completely differently. When you request a Service of the same name, you'll be getting back the same interface, but with a different underlying implementation. It's awkward enough that you'd have to query the Collection for its absolute path, and then pass that absolute path to the Database to resolve the Service, but add to that the fact that when you offload Service resolution responsibilities to the Database, you're asking it not only to get a Service, but to get a specific implementation based on the Collection name you're passing to it, which is more responsibility than the Database needs to handle, especially in a system where the collection structure is based on many heterogeneous data sources and implementations. -- Tom Bradford - http://www.tbradford.org Apache Xindice (Native XML Database) - http://xml.apache.org Project Labrador (Web Services Framework) - http://notdotnet.org -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Remarks about XML:DB API
On Thursday, February 7, 2002, at 02:40 PM, Tom Bradford wrote: On Thursday, February 7, 2002, at 02:30 PM, Dare Obasanjo wrote: This can easily be supported by doing what I did with SiXDML. Just add getService(String, String) to the Database class. Here's the problem with that though. Imagine you have a program that performs service requests in a generic fashion against Collections that are passed to it. Now furthermore, say you have two collections, one is a collection that is relationally mapped, the other that is native. Because of this, the Service may have to be implemented completely differently. When you request a Service of the same name, you'll be getting back the same interface, but with a different underlying implementation. It's awkward enough that you'd have to query the Collection for its absolute path, and then pass that absolute path to the Database to resolve the Service, but add to that the fact that when you offload Service resolution responsibilities to the Database, you're asking it not only to get a Service, but to get a specific implementation based on the Collection name you're passing to it, which is more responsibility than the Database needs to handle, especially in a system where the collection structure is based on many heterogeneous data sources and implementations. I don't think he was suggesting that this should be the only way to access collections just an addendum. The one problem I do see with it is that it changes the concept of the Database. In the current API you shouldn't be using the database instance for anything beyond the initial setup. If we move logic like getService into it then you'll actually be using the Database instance in other places as well. Not a major problem, but not as simple as just adding one method. We'd probably need a method on Collection to return the Database instance. Or another option would be to change the getService method to enable specification of what scope the service applies too. I almost like that better. Collection.getService(name, version, scope) where scope is one of three values, database, collection, or hierachy. These could be defined as constants in the Service interface. Hierarchy would apply to the collection and all children of the collection. Either way would work though. -- Tom Bradford - http://www.tbradford.org Apache Xindice (Native XML Database) - http://xml.apache.org Project Labrador (Web Services Framework) - http://notdotnet.org -- 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/ --
