Обсуждение: XQuery support
Hi, I know this has been discussed several times and it seems the conclusin was it's impossible if we would like to use existing XQuery external modules (some are by license reasons and some are by techinical reasons). So it seems the only way to support XQuery is, developing our own XQuery functionality from scratch. I'm wondering if other people reach the same conclusion as me, or is it a totaly impossible project? -- Tatsuo Ishii SRA OSS, Inc. Japan
Tatsuo Ishii wrote: > Hi, > > I know this has been discussed several times and it seems the > conclusin was it's impossible if we would like to use existing XQuery > external modules (some are by license reasons and some are by > techinical reasons). > > So it seems the only way to support XQuery is, developing our own > XQuery functionality from scratch. I'm wondering if other people reach > the same conclusion as me, or is it a totaly impossible project? > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > Well xquilla on top of xerces should get us pretty much were we need to go. They are both under the Apache 2 license, which I believe would be ok. But they are C++ so I don't know if we could use them. I found Zorba, its C++ and Apache 2. But I don't know much about it. But it looks promising. http://www.zorba-xquery.com/ Sedna is a complete db/xquery solution licensed under Apache 2 and written in C/C++. Perhaps we could use pieces of this. Better than starting from scratch. http://modis.ispras.ru/sedna/index.html Scott
>> I know this has been discussed several times and it seems the >> conclusin was it's impossible if we would like to use existing XQuery >> external modules (some are by license reasons and some are by >> techinical reasons). >> >> So it seems the only way to support XQuery is, developing our own >> XQuery functionality from scratch. I'm wondering if other people reach >> the same conclusion as me, or is it a totaly impossible project? > Well xquilla on top of xerces should get us pretty much were we need to go. They are both under the Apache 2 license, whichI believe would be ok. But they are C++ so I don't know if we could use them. > I found Zorba, its C++ and Apache 2. But I don't know much about it. But it looks promising. > http://www.zorba-xquery.com/ Sounds like a great project. Please, let us know (zorba-users@lists.sourceforge.net) if you need any help or have questionswith regard to plugging Zorba to PostGreSQL. We would love to see this happen and help. Best regards, Matthias
Matthias Brantner wrote: >>> I know this has been discussed several times and it seems the >>> conclusin was it's impossible if we would like to use existing XQuery >>> external modules (some are by license reasons and some are by >>> techinical reasons). >>> >>> So it seems the only way to support XQuery is, developing our own >>> XQuery functionality from scratch. I'm wondering if other people reach >>> the same conclusion as me, or is it a totaly impossible project? >>> > > >> Well xquilla on top of xerces should get us pretty much were we need to go. They are both under the Apache 2 license,which I believe would be ok. But they are C++ so I don't know if we could use them. >> I found Zorba, its C++ and Apache 2. But I don't know much about it. But it looks promising. >> http://www.zorba-xquery.com/ >> > Sounds like a great project. Please, let us know (zorba-users@lists.sourceforge.net) if you need any help or have questionswith regard to plugging Zorba to PostGreSQL. We would love to see this happen and help. > > > Well, maybe you can answer the questions I had last time I looked at it, namely: > XQuery is a whole other question. Adding another library dependency is > something we try to avoid. Zorba <http://www.zorba-xquery.com/> might > work, but it appears to have its own impressive list of dependencies > (why does it require both libxml2 and xerces-c? That looks a bit > redundant.) > > Even if we did implement XMLTABLE, I think I'd probably be inclined to > start by limiting it to plain XPath, without the FLWOR stuff. I think > that would satisfy the vast majority of needs, although you might feel > differently. (Do a Google for XMLTABLE - every example I found uses > plain XPath expressions.) A much more urgent need we have, IMNSHO, than for XQuery, is for XSLT support that actually works. But maybe that's just me. cheers andrew
Andrew Dunstan wrote: > > > Matthias Brantner wrote: >>>> I know this has been discussed several times and it seems the >>>> conclusin was it's impossible if we would like to use existing XQuery >>>> external modules (some are by license reasons and some are by >>>> techinical reasons). >>>> >>>> So it seems the only way to support XQuery is, developing our own >>>> XQuery functionality from scratch. I'm wondering if other people reach >>>> the same conclusion as me, or is it a totaly impossible project? >>>> >> >> >>> Well xquilla on top of xerces should get us pretty much were we need >>> to go. They are both under the Apache 2 license, which I believe >>> would be ok. But they are C++ so I don't know if we could use them. >>> I found Zorba, its C++ and Apache 2. But I don't know much about it. >>> But it looks promising. >>> http://www.zorba-xquery.com/ >>> >> Sounds like a great project. Please, let us know >> (zorba-users@lists.sourceforge.net) if you need any help or have >> questions with regard to plugging Zorba to PostGreSQL. We would love >> to see this happen and help. >> >> >> > > Well, maybe you can answer the questions I had last time I looked at it, > namely: > >> XQuery is a whole other question. Adding another library dependency is >> something we try to avoid. Zorba <http://www.zorba-xquery.com/> might >> work, but it appears to have its own impressive list of dependencies >> (why does it require both libxml2 and xerces-c? That looks a bit >> redundant.) >> >> Even if we did implement XMLTABLE, I think I'd probably be inclined to >> start by limiting it to plain XPath, without the FLWOR stuff. I think >> that would satisfy the vast majority of needs, although you might feel >> differently. (Do a Google for XMLTABLE - every example I found uses >> plain XPath expressions.) > > A much more urgent need we have, IMNSHO, than for XQuery, is for XSLT > support that actually works. But maybe that's just me. I've been playing around with Zorba and xQilla today. I couldn't actually get Zorba to build on my system. It looks like the two share a common (or similar) C API though. Zorba also had perl, Python, Ruby and PHP bindings (which I also couldn't get to work) but would be nice to be able to use from plperl, plpython, plruby also. If it were possible to drop the xerces dependency from Zorba and use libxml2 for parsing, that would be a strong case for it. The other big dependency for Zorba was ICU for converting character sets. I'm not familiar with that part of Postgres. But it seems to me that we would have our own libraries for that sort of thing. I'm not a big fan of doing XSLT in the database. But xQilla would give you XSLT 2.0 support. Scott
Scott Bailey <artacus@comcast.net> writes:
> If it were possible to drop the xerces dependency from Zorba and use
> libxml2 for parsing, that would be a strong case for it. The other big
> dependency for Zorba was ICU for converting character sets. I'm not
> familiar with that part of Postgres. But it seems to me that we would
> have our own libraries for that sort of thing.
ICU has been an, ahem, bone of contention. Check the archives.
But a patch that depends on it for some second-order reason seems
unlikely to get accepted.
regards, tom lane
> Well, maybe you can answer the questions I had last time I looked at it, namely: > >> XQuery is a whole other question. Adding another library dependency is something we try to avoid. Zorba <http://www.zorba-xquery.com/>might work, but it appears to have its own impressive list of dependencies (why does it requireboth libxml2 and xerces-c? That looks a bit redundant.) In Zorba, we use libxml2 for parsing XML documents. This dependency is specific to a particular store implementation. For instance, a store on top of PostgreSQL could use any parser for importing XML documents. The xerces-c dependency is used for providing XML Schema support. If you do not want to provide this functionality in a first step, you can simply switch it off at compile time and xerces-c will not be required. The same is also valid for the ICU dependency which is used for Unicode support. Specifically, Zorba uses it for regular expression evaluation and collation support. Best regards Matthias
> I've been playing around with Zorba and xQilla today. I couldn't actually get Zorba to build on my system. It looks likethe two share a common (or similar) C API though. Yes, Zorba and XQilla both implement the XQC API. It was developed by the Zorba and XQilla teams in a joint effort. The project itself is hosted on sf at http://sourceforge.net/projects/xqc/. A brief intro doc can be found at http://www.zorba-xquery.com/doc/xqc_intro.pdf. > Zorba also had perl, Python, Ruby and PHP bindings (which I also couldn't get to work) but would be nice to be able touse from plperl, plpython, plruby also. It would be great if we could work together on this over at the zorba-users list. > If it were possible to drop the xerces dependency from Zorba and use libxml2 for parsing, that would be a strong case forit. The other big dependency for Zorba was ICU for converting character sets. I'm not familiar with that part of Postgres.But it seems to me that we would have our own libraries for that sort of thing. Please find answers to this in my previous email. Thanks & best regards, Matthias