RE: W3C_XML_Query_Sevice
Hello Gianugo, I must admit that I am thinking about the Service more from the perspective of someone looking to add support for XQuery to an implementation that already has the XPath Service, and has people already using that XPath Service. To handle this I would like to introduce a new Service so that code built on the XPath service will work in the same way without any changes. New code can take advantage of XQuery via the new Service, and old code can be migrated to XQuery at a time convenient for its developer (and clearly "never" must be an option!). Your point about how decoupled XQuery is from document instances is a good one. I seem to remember that in the past there was some general discussion about the advantages and disadvantages of binding a Service to a Collection Do you have an idea for an alternative approach? I was thinking that adding a new Service would fit nicely with the character of the API, but perhaps there are sufficient arguments for introducing a new class (XQueryEngine?) to the API - one which is not tied to a Collection? I could see the interface being quite simple - perhaps just a method accepting the query as a parameter and returning a ResourceSet, as with the XPathQueryService. Depending on how individual datastores implement XQuery, maybe a generic method to configure the underlying XQuery engine would also be useful. Greetings, Trevor. > I for one would welcome this Service. The only problem I envision is > that XQuery is *very* decoupled from a document instance or even a > Collection (given its (ab?)use of document() functionalities) so it > doesn't really make sense to have it bound to a particular collection. > > How do you see this Service implemented? > > Ciao, > > -- > Gianugo Rabellino > CTO > Pro-netics s.r.l. > http://www.pro-netics.com -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
RE: FW: Configuring an XML:DB database
Hello Everyone, I would also like to know the status of this task! Thanks, Trevor. -Original Message- From: Vladimir R. Bossicard [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 6:04 AM To: [EMAIL PROTECTED] Subject: Re: FW: Configuring an XML:DB database Hi all, any news on this? -Vladimir -- Vladimir R. Bossicard www.bossicard.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/ --
W3C_XML_Query_Sevice
Hello Everyone, are there any plans to add a new Service interface to the working draft for handling XML Query? I am thinking about how best to add XML Query support to our implementation, and would prefer to remain standard conformant rather than blazing my own trail. Does anyone already have a Service implementation for handling XML Query? Thanks in advance, Trevor. -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
RE: SiDXML
Hello. Maybe the following link is the best answer to this question: http://www.xmldb.org/sixdml/index.html Cheers, Trevor. -Original Message- From: Gilles Dodinet [mailto:[EMAIL PROTECTED] Sent: Friday, January 03, 2003 3:28 PM To: [EMAIL PROTECTED] Subject: SiDXML hi - another question.. what do you think about SiDXML ? (http://sixdml.sourceforge.net/) thanks -- gd -- 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: Addition to XAPI: getNames()
> simply use the "deprecated" flag for the getName() method. > Indeed! > I thought about : > Iterator getNames() > > and maybe > String[] getNames() > > would be better since it's much easier to initialize statically > I would also prefer the second version (return a String[]), because this feels like it fits in better with the API's style (as there are already a few methods which return arrays, but none which return an Iterator). In addition, having the entries in a String[] saves users from casting Iterator contents to Strings when iterating through them. > -Vladimir > > -- > Vladimir R. Bossicard > www.bossicard.com Cheers, Trevor. -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
RE: Addition to XAPI: getNames()
> Ok, I would like to add this extension. But what's the behaviour of a > vendor implementation? Does such an implementation needs to implement > both getters for a single name and a sequence of names? > Does registerDatabase() need to retrieve names through both getters? > I see getName() as a special case of getNames() so may be we should > omit the getName() method? Whilst I agree that getName() is a special case of getNames(), isn't it perhaps a bit harsh to remove getName() - this would break all of the applications which are directly using the getName() method. (Even if all driver vendors update their implementations immediately.) Perhaps it is better to leave it in, but making it clear that the method will be removed later? > Kindest regards, Lars Thanks, Trevor. -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
BinaryResources and MIME types
Hello Everyone. I received a question about how to store the MIME type for an instance of BinaryResource. Looking through the mailing list archives I found some discussions about this topic from about two years ago - but it seems that there isn't anything in the September 2001 draft or the API use cases. Am I overlooking something? How are other people handling "types" for binary data? Thanks, Trevor. -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Software AG releases XML:DB API implementation for Tamino
Software AG is pleased to announce the availability of an XML:DB API implementation for its Tamino XML Server. Please see here: http://developer.softwareag.com/tamino/xmldb/Default.htm for more details and download links. Regards, Trevor. -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Q: Schema for ResourceSet.getMembersAsResource()
Hello Everyone. The subject says it all: what is the progress of defining a schema for [the result of] the "getMembersAsResource()" method of "ResourceSet" ? Is there some "work in progress" level design document that I have overlooked? Thanks, Trevor. -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Q: Intent of ResourceSet.addResource() / removeResource()
Hello Everyone. This question is more implementation oriented: should the "addResource()" and "removeResource()" methods of "ResourceSet" operate persistently? (That is, should removing a Resource from a ResourceSet remove it from the underlying datastore too? Or just remove it from the ResourceSet and leave the datastore untouched?) Or is the intent of these methods more to allow "in memory" manipulation of sets (which may be composed of Resources obtained from various sources)? Thanks, Trevor. -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Q: Types / Sizes
Hello Everyone. In the JavaDoc for "Collection", the method "getResourceCount()" is defined to have a return type of "int". The JavaDoc for the "getSize()" method of "ResourceSet" shows a return type of "long" This seems rather mysterious: a ResourceSet can theorectically hold more Resources than a Collection - is this intentional? (For example, so that a ResourceSet may contain Resources from multiple Collections - perhaps the results of a query which searched through a Collection *and* its Child Collections?) Thanks, Trevor. -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Q: Packages
Hello Everyone. A design point question: what is the reason for having ResourceSet in the "base" package, when it is only used in the "modules" package? A question which follows on from the first is: why are there two packages? It looks as if there are two packages to make the "Core Levels" easier to define, but the separation isn't quite clean: "Core Level 0" now consists of implementing everything in "base" and "XMLResource" from "modules". Are there any plans to revise the API in this respect? (Perhaps to move everything into the same package [as with JDBC], or a more complex re-assignment of certain interfaces?) Thanks, Trevor. -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Q: General Requirement and XMLDBException
> Hello Everyone. > > Given that all of the listed implementations are in Java, are there any > plans to evolve the requirement that "The API MUST NOT preclude the usage > with more than one language binding" into something more relaxed (and > perhaps more in the favour of Object Oriented languages)? > > A follow on question (that may be irrelevant with the answer to the first) > is: are there any plans to evolve the design of XMLDBException? > Having one Exception class, with the meaning buried inside isn't very > Object Oriented! Having a richer Exception hierarchy (based upon the > values/fields in ErrorCodes) would make the Java implementations > "cleaner". > > Thanks, > Trevor. -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
