xmldb-org-general Mailing List for XML:DB Initiative for XML Databases
Brought to you by:
reinhapa
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(13) |
Jul
|
Aug
|
Sep
(16) |
Oct
(5) |
Nov
(4) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(9) |
Feb
(7) |
Mar
(7) |
Apr
(12) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2008 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Patrick R. <rei...@us...> - 2013-07-06 20:00:27
|
Update of /cvsroot/xmldb-org/./.settings In directory sfp-cvs-1.v30.ch3.sourceforge.com:/tmp/cvs-serv7100/.settings Added Files: org.eclipse.jdt.core.prefs Log Message: added eclipse project files --- NEW FILE: org.eclipse.jdt.core.prefs --- eclipse.preferences.version=1 org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7 org.eclipse.jdt.core.compiler.codegen.unusedLocal=preserve org.eclipse.jdt.core.compiler.compliance=1.7 org.eclipse.jdt.core.compiler.debug.lineNumber=generate org.eclipse.jdt.core.compiler.debug.localVariable=generate org.eclipse.jdt.core.compiler.debug.sourceFile=generate org.eclipse.jdt.core.compiler.problem.assertIdentifier=error org.eclipse.jdt.core.compiler.problem.enumIdentifier=error org.eclipse.jdt.core.compiler.source=1.7 |
From: Patrick R. <rei...@us...> - 2013-07-06 20:00:23
|
Update of /cvsroot/xmldb-org/.settings In directory sfp-cvs-1.v30.ch3.sourceforge.com:/tmp/cvs-serv7091/.settings Log Message: Directory /cvsroot/xmldb-org/.settings added to the repository |
From: Ronald B. <rpb...@rp...> - 2008-02-13 03:55:16
|
Hello, XQuery provides this only through the fn:normalize-space() function. For example: /animals/animal[fn:normalize-space(.)="dog"] (Note that the boundary-space declaration does not apply in this case.) I don't know if eXist has any special capabilities here. -- Ron P.S. For XQuery questions, you will have better luck with the XQuery-talk mailing list: http://www.x-query.com/mailman/listinfo/talk For eXist questions, try the exist-open mailing list: https://lists.sourceforge.net/lists/listinfo/exist-open Marc Miranda wrote: > Hi friends, > > I would be very if you could help me we just a little question. > How can I tell org.exist.xmldb.XQueryService or maybe > org.xmldb.api.base.Collection not to process whitespaces between tags > when executing a xquery? Is there any possiblity that code makes an internal > trim()? Maybe some property? > > <animals> > <animal>dog</animal> > <animal> dog </animal> > <animals> > > I would like that an xQuery with *animal="dog"* doesn't make distinction. > Thank you very much inadvance... |
From: Marc M. <nig...@gm...> - 2008-02-13 01:37:39
|
Hi friends, I would be very if you could help me we just a little question. How can I tell org.exist.xmldb.XQueryService or maybe org.xmldb.api.base.Collection not to process whitespaces between tags when executing a xquery? Is there any possiblity that code makes an internal trim()? Maybe some property? <animals> <animal>dog</animal> <animal> dog </animal> <animals> I would like that an xQuery with *animal="dog"* doesn't make distinction. Thank you very much inadvance... |
From: Martin P. <ma...@ma...> - 2006-10-06 20:28:51
|
> Did anyone ever respond to you in private, because I didn't see > anything > public. I've wanted to help with XUpdate, but I haven't had cycles > for > even that/ I'd love to see progress on XAPI, but I have no idea > whether > there is any interest. > > If you have moved on in the past 6 months, what technology did you > wind > up moving on to? Something proprietary? No idea what he did, but I think we will see the first implementations of the XQuery Updates Draft soon (I implemented it for X-Hive/DB already). XUpdate seems to be completely dead, judging from customer demand and actual use of what we ship. Regards, Martin |
From: Uche O. <uch...@fo...> - 2006-10-06 17:34:09
|
Colin Saxton wrote: > I am interested in contributing/helping develop the API. Is there an > agenda for moving the specification forward? Did anyone ever respond to you in private, because I didn't see anything public. I've wanted to help with XUpdate, but I haven't had cycles for even that/ I'd love to see progress on XAPI, but I have no idea whether there is any interest. If you have moved on in the past 6 months, what technology did you wind up moving on to? Something proprietary? -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Articles: http://uche.ogbuji.net/tech/publications/ |
From: Colin S. <col...@nt...> - 2006-04-19 20:28:19
|
I am interested in contributing/helping develop the API. Is there an agenda for moving the specification forward? |
From: Per N. <per...@us...> - 2005-08-06 13:17:50
|
Saw this on the eXists mailing list: ---------- Vidarebefordrat brev ---------- Subject: [Exist-open] Spring XML Database Framework Released Date: Wednesday 08 December 2004 15.20 From: Stuart Eccles <st...@co...> To: exi...@li... As part of a much larger project i have released a framework for integrating Spring with XML databases on an open source license. The Spring XMLDB framework is designed to ease the use of XML databases with the spring framework. It provides configurable generic beans for dataaccess to XML databases. Key features are * Pooling of collection connections to XML databases through the XML:DB API * Generic DAOs for querying with XPath, XQuery and XUpdate as well as retrieving/storing documents (binary and XML) and managing collections and databases themselves. * Embedded startup of XML databases using Spring configured beans. * Import/Export from file systems to XML databases using Spring resource abstraction framework. * Generic Spring controllers for configuring queries on XML databases which can then be displayed through XSLT views or using JSTL tags. * Generic Tiles controllers for integrating query results into tiles components, allowing content display to be controlled in definitions * 2 sample applications. A XML database manager in Spring and a Spring-Tiles news site. Currently supported XML databases are eXist and xindice. The project can be found on sourceforge at http://sourceforge.net/projects/springxmldb/ and downloaded from http://prdownloads.sourceforge.net/springxmldb/springxmldb-0.1-src.zip?downlo ad Hope this is useful to someone. Stuart Eccles ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Exist-open mailing list Exi...@li... https://lists.sourceforge.net/lists/listinfo/exist-open ------------------------------------------------------- |
From: Uche O. <Uch...@fo...> - 2005-04-26 15:27:21
|
On Sun, 2005-04-24 at 10:33 -0600, Uche Ogbuji wrote: > I don't have time, but I'm speaking in the possibly vain hope that I can > find a way to carve out a few slices here and there. I at least found the time for this: http://www.oreillynet.com/pub/wlg/6935 -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-xml.html Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/ Schema standardization for top-down semantic transparency - http://www-128.ibm.com/developerworks/xml/library/x-think31.html |
From: Uche O. <uch...@fo...> - 2005-04-24 16:33:17
|
On Sun, 2005-04-24 at 17:44 +0200, Per Nyfelt wrote: > s=F6ndagen den 24 april 2005 16.11 skrev Uche Ogbuji: > > > > Maybe create a separate "xupdate" project on SourceForge? > > > > > > > > Maybe get xupdate.org? > > > > > > If it grows big then yes but I do not see the need for that right n= ow. > > > > Well, at the very least we should move Kimbro's use cases to the same > > place as the specs. >=20 > Yes, good idea. Since it seems you have some time to devote to this I l= ike to=20 > propose you as committer on the project and also ability to update the = web=20 > pages. Please let me know if I have understood you correctly and this i= s in=20 > line with your ideas. I don't have time, but I'm speaking in the possibly vain hope that I can find a way to carve out a few slices here and there. Go ahead and add me as a committer. SF id is "uche". I'll do what I can. If you contact Kimbro about the links, please also ask about permission to copy his use-cases page. I'm quite sure I can at least muster time to copy those files over. > > I'd still like to know if I'm missing any implementations from my lis= t > > > > (or if I have any stale info): >=20 > Ozone also supports XUpdate. Thanks. --=20 Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/ed= u/x-dw-x-xmlcss2-i.html XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-x= ml.html Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.= com/developerworks/xml/library/x-oocalc/ Schema standardization for top-down semantic transparency - http://www-12= 8.ibm.com/developerworks/xml/library/x-think31.html |
From: Per N. <per...@us...> - 2005-04-24 15:45:06
|
s=F6ndagen den 24 april 2005 16.11 skrev Uche Ogbuji: > snip... > > > 3) A clear location. Maybe: > > > > > > http://www.xmldatabases.org/xupdate ? > > > > Currently it is > > http://xmldb-org.sourceforge.net/xupdate/ > > > > is that not clear? > > I would have thought so, but if you look at the XML-DEV thread which i > posted, apparently others don't think so. I think it is probably a case of not enough links to the site in the right= =20 places. I someone could ask Kimbro to add a link to to the current location= =20 of the XML:DB home page (http://xmldb-org.sourceforge.net ) and Xupdate=20 (http://xmldb-org.sourceforge.net/xupdate/) that would be great. > > > > Maybe create a separate "xupdate" project on SourceForge? > > > > > > Maybe get xupdate.org? > > > > If it grows big then yes but I do not see the need for that right now. > > Well, at the very least we should move Kimbro's use cases to the same > place as the specs. Yes, good idea. Since it seems you have some time to devote to this I like = to=20 propose you as committer on the project and also ability to update the web= =20 pages. Please let me know if I have understood you correctly and this is in= =20 line with your ideas. > > I'd still like to know if I'm missing any implementations from my list > > (or if I have any stale info): Ozone also supports XUpdate. > > > Could anyone help me compile a list of implementations? I'll start by > > > mentioning the ones I know: > > > > > > * 4Suite. http://4suite.org XUpdate command line tool and Python API > > > * xmldiff - XUpdate-based XML diff and merge in Python > > > * XIndice > > > * eXist > > > * Lexus > > > * dbxml > > > * Orbeon > > > * X-Hive > > > * Jaxup (http://klomp.org/jaxup/) > > > * Mobius Mako Command Line Utilities > > > http://projectmobius.osu.edu/docs/makocl.php > > > * RxUpdate (http://rx4rdf.liminalzone.org/RxUpdate), and "enhanced" > > > implementation > > > * XML-XUpdate-LibXML (http://search.cpan.org/~pajas/XML-XUpdate- > > > LibXML-0.5.0/), Perl implementation > > > > > > Thanks. Best regards, Per |
From: Uche O. <uch...@fo...> - 2005-04-24 14:11:40
|
On Sun, 2005-04-24 at 15:38 +0200, Per Nyfelt wrote: > s=F6ndagen den 24 april 2005 07.41 skrev Uche Ogbuji: > > Well, folks seem to be eager to write XUpdate off: > > > > http://lists.xml.org/archives/xml-dev/200504/msg00678.html > > > > Personally, I think XUpdate is one of the most successful and useful > > outputs of XML:DB, and that it's worth some effort to save from any > > supposed obsolescence. > > > > I think we have several problems: > > > > 1) The mailings lists are spam-ridden. XUpdate is especially hard hi= s. > > I can imagine it's driven a lot of folks away. Doesn't SF have some > > sort of spam control? If not, should we consider a Google group for > > XUpdate? I'm willing to take on the task to set one up, if need be. >=20 > Yes I did set up spam control about 1-2 months ago. As you probably hav= e seen,=20 > there is no spam coming in anymore. I haven't seen that. My own spam filters never let any through, so I didn't notice all the spam until I looked at the archives. Thanks for installing the controls. > > 3) A clear location. Maybe: > > > > http://www.xmldatabases.org/xupdate ? >=20 > Currently it is > http://xmldb-org.sourceforge.net/xupdate/ >=20 > is that not clear? I would have thought so, but if you look at the XML-DEV thread which i posted, apparently others don't think so. > > Maybe create a separate "xupdate" project on SourceForge? > > > > Maybe get xupdate.org? >=20 > If it grows big then yes but I do not see the need for that right now. Well, at the very least we should move Kimbro's use cases to the same place as the specs. I'd still like to know if I'm missing any implementations from my list (or if I have any stale info): > > Could anyone help me compile a list of implementations? I'll start b= y > > mentioning the ones I know: > > > > * 4Suite. http://4suite.org XUpdate command line tool and Python API > > * xmldiff - XUpdate-based XML diff and merge in Python > > * XIndice > > * eXist > > * Lexus > > * dbxml > > * Orbeon > > * X-Hive > > * Jaxup (http://klomp.org/jaxup/) > > * Mobius Mako Command Line Utilities > > http://projectmobius.osu.edu/docs/makocl.php > > * RxUpdate (http://rx4rdf.liminalzone.org/RxUpdate), and "enhanced" > > implementation > > * XML-XUpdate-LibXML (http://search.cpan.org/~pajas/XML-XUpdate- > > LibXML-0.5.0/), Perl implementation > > > > Thanks. --=20 Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/ed= u/x-dw-x-xmlcss2-i.html XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-x= ml.html Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.= com/developerworks/xml/library/x-oocalc/ Schema standardization for top-down semantic transparency - http://www-12= 8.ibm.com/developerworks/xml/library/x-think31.html |
From: Per N. <per...@us...> - 2005-04-24 13:41:17
|
s=F6ndagen den 24 april 2005 07.41 skrev Uche Ogbuji: > Well, folks seem to be eager to write XUpdate off: > > http://lists.xml.org/archives/xml-dev/200504/msg00678.html > > Personally, I think XUpdate is one of the most successful and useful > outputs of XML:DB, and that it's worth some effort to save from any > supposed obsolescence. > > I think we have several problems: > > 1) The mailings lists are spam-ridden. XUpdate is especially hard his. > I can imagine it's driven a lot of folks away. Doesn't SF have some > sort of spam control? If not, should we consider a Google group for > XUpdate? I'm willing to take on the task to set one up, if need be. Yes I did set up spam control about 1-2 months ago. As you probably have se= en,=20 there is no spam coming in anymore. > > 2) Finally wrapping up the specs. I <gulp> volunteer to make a first > pass at it, depending on resolution of other points I've brought up. Great! > > 3) A clear location. Maybe: > > http://www.xmldatabases.org/xupdate ? Currently it is http://xmldb-org.sourceforge.net/xupdate/ is that not clear? > > Maybe create a separate "xupdate" project on SourceForge? > > Maybe get xupdate.org? If it grows big then yes but I do not see the need for that right now. > > Could anyone help me compile a list of implementations? I'll start by > mentioning the ones I know: > > * 4Suite. http://4suite.org XUpdate command line tool and Python API > * xmldiff - XUpdate-based XML diff and merge in Python > * XIndice > * eXist > * Lexus > * dbxml > * Orbeon > * X-Hive > * Jaxup (http://klomp.org/jaxup/) > * Mobius Mako Command Line Utilities > http://projectmobius.osu.edu/docs/makocl.php > * RxUpdate (http://rx4rdf.liminalzone.org/RxUpdate), and "enhanced" > implementation > * XML-XUpdate-LibXML (http://search.cpan.org/~pajas/XML-XUpdate- > LibXML-0.5.0/), Perl implementation > > Thanks. |
From: Uche O. <Uch...@fo...> - 2005-04-24 05:41:53
|
Well, folks seem to be eager to write XUpdate off: http://lists.xml.org/archives/xml-dev/200504/msg00678.html Personally, I think XUpdate is one of the most successful and useful outputs of XML:DB, and that it's worth some effort to save from any supposed obsolescence. I think we have several problems: 1) The mailings lists are spam-ridden. XUpdate is especially hard his. I can imagine it's driven a lot of folks away. Doesn't SF have some sort of spam control? If not, should we consider a Google group for XUpdate? I'm willing to take on the task to set one up, if need be. 2) Finally wrapping up the specs. I <gulp> volunteer to make a first pass at it, depending on resolution of other points I've brought up. 3) A clear location. Maybe: http://www.xmldatabases.org/xupdate ? Maybe create a separate "xupdate" project on SourceForge? Maybe get xupdate.org? Could anyone help me compile a list of implementations? I'll start by mentioning the ones I know: * 4Suite. http://4suite.org XUpdate command line tool and Python API * xmldiff - XUpdate-based XML diff and merge in Python * XIndice * eXist * Lexus * dbxml * Orbeon * X-Hive * Jaxup (http://klomp.org/jaxup/) * Mobius Mako Command Line Utilities http://projectmobius.osu.edu/docs/makocl.php * RxUpdate (http://rx4rdf.liminalzone.org/RxUpdate), and "enhanced" implementation * XML-XUpdate-LibXML (http://search.cpan.org/~pajas/XML-XUpdate- LibXML-0.5.0/), Perl implementation Thanks. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-xml.html Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/ Schema standardization for top-down semantic transparency - http://www-128.ibm.com/developerworks/xml/library/x-think31.html |
From: Ronald B. <rpb...@rp...> - 2005-04-14 18:28:07
|
Finally had time to read this... Per Nyfelt wrote: > Hi Travis, > > onsdagen den 16 mars 2005 18.26 skrev Travis Stevens: > >>I would like to address the relationship of the XAPI with the >>Xinclude[1] specification. XInclude is a specification for merging XML >>documents. The basic example is including an XML document at a given URL. >> >><?xml version='1.0'?> >><document xmlns:xi="http://www.w3.org/2001/XInclude"> >> <p>120 Mz is adequate for an average home user.</p> >> <xi:include href="disclaimer.xml"/> >></document> >> >>One should be able to specify a resource in an XML:DB database in a >>standard way. A simple idea would be to reference the resource by ID: >><xi:include >>href="xmldb:vendorx://db.xmlmovies.com:2030/movies?resourceId=5" />. > > > Looks good to me. +1 >>Should xpath and xquery also be allowed as part of the URI? > > > XQuery is not yet fully integrated in the API. I did an intial attempt heavily > inspired by the eXists implementaiton but there is no reference > implementation yet and the whole thing needs some refinement before it is > ready. I think we need to finalize how XQuery works with the API before > extending your basic idea of referencing a' la xinclude to also include > xquery. I see nothing bad with allowing xpath expressions as part of the URI > though. I'm less sure of this. XInclude already allows XPointer addressing into the included document, so XPath/XQuery seems a bit too much. It might make more sense to have a URI-based version of XAPI, which would then use XQuery or XPath. This could then be used in an XInclude statement. -- Ron |
From: Uche O. <Uch...@fo...> - 2005-04-14 03:43:40
|
On Fri, 2005-04-08 at 00:18 +0200, Per Nyfelt wrote: > I also think it is is important to not alienate existing implementers of the > API by introducing incompatible changes. Besides eXist and Xindice there are > several commercial vendors as well. On the other hand, there are several > extension to the API made by those vendors that I hope to see in the API > (XQuery support was the last one I added heavily inspired by eXist but it is > just an early draft). I would prefer extension, compatibility and deprecation > rather than incompatible changes whenever possible. Of your three choices > below I'm between 1 and 2 but closest to 2, especially if we can maintain > backward compatibility by deprecation rather than removal of functionality. +1 -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html Writing and Reading XML with XIST - http://www.xml.com/pub/a/2005/03/16/py-xml.html Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/ Schema standardization for top-down semantic transparency - http://www-128.ibm.com/developerworks/xml/library/x-think31.html |
From: Ronald B. <rpb...@rp...> - 2005-04-08 05:20:39
|
I lean most strongly towards 2. There's no need to arbitrarily change things, but I also don't feel too strongly about breaking backwards compatibility if there is a compelling reason. (Of note, I have no real stake here, as I am not using the XML:DB API.) One thing that would help with this decision is trying to estimate how many people actually use the API. There is a big difference between breaking 10 applications or thousands of applications. For example, eXist supports a number of different APIs, and one could at least vaguely estimate their relative usage by looking at the eXist mailing list. Also, are there any commercial (or even private) applications that depend on XML:DB to allow switching of native XML database backends? I do agree that deprecation, rather than outright deletion, of interfaces is preferrable. -- Ron Per Nyfelt wrote: > I also think it is is important to not alienate existing implementers of the > API by introducing incompatible changes. Besides eXist and Xindice there are > several commercial vendors as well. On the other hand, there are several > extension to the API made by those vendors that I hope to see in the API > (XQuery support was the last one I added heavily inspired by eXist but it is > just an early draft). I would prefer extension, compatibility and deprecation > rather than incompatible changes whenever possible. Of your three choices > below I'm between 1 and 2 but closest to 2, especially if we can maintain > backward compatibility by deprecation rather than removal of functionality. > > Best regards, > Per |
From: Per N. <per...@us...> - 2005-04-07 22:18:49
|
I also think it is is important to not alienate existing implementers of the API by introducing incompatible changes. Besides eXist and Xindice there are several commercial vendors as well. On the other hand, there are several extension to the API made by those vendors that I hope to see in the API (XQuery support was the last one I added heavily inspired by eXist but it is just an early draft). I would prefer extension, compatibility and deprecation rather than incompatible changes whenever possible. Of your three choices below I'm between 1 and 2 but closest to 2, especially if we can maintain backward compatibility by deprecation rather than removal of functionality. Best regards, Per torsdagen den 7 april 2005 17.49 skrev Travis Stevens: > I have been tasked with modifying the XML:DB XAPI standard. I have been > reading the lists to identify suggestions for evolving the standard. > Some of which would require the API to be modified substantially. > > I need some help determining how I should approach suggestions which > would require incompatible changes to the API. > > 1. Ignore the suggestions completely -- It is very important that the > evolved API is compatible with the current API. > 2. Case by case -- It would be nice to have the evolved API compatible > with the current API, but we will accept some modification. > 3. Lessons learned -- We will accept major modifications to the evolved > API. > > -Trav > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Xmldb-org-general mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmldb-org-general |
From: Gunderson, J. <jgu...@ci...> - 2005-04-07 17:13:15
|
I would prefer compatibility unless an outstanding case could be made for "some modification". I think the actual API definition is pretty simple and at high level so lots could be done without make it incompatible. Do you have an initial "idea" list? I would like to see: * versioning; * checkin/checkout (or equivalent locking facility) * user grants by collection. If these are of interest we could propose how they might look. Thanks, Jeff -----Original Message----- From: xml...@li... [mailto:xml...@li...] On Behalf Of Travis Stevens Sent: Thursday, April 07, 2005 11:50 AM To: xml...@li... Subject: [Xmldb-org-general] Modifying the XML:DB standard, question 1 I have been tasked with modifying the XML:DB XAPI standard. I have been reading the lists to identify suggestions for evolving the standard. =20 Some of which would require the API to be modified substantially. I need some help determining how I should approach suggestions which=20 would require incompatible changes to the API. 1. Ignore the suggestions completely -- It is very important that the=20 evolved API is compatible with the current API. 2. Case by case -- It would be nice to have the evolved API compatible=20 with the current API, but we will accept some modification. 3. Lessons learned -- We will accept major modifications to the evolved API. -Trav ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick _______________________________________________ Xmldb-org-general mailing list Xml...@li... https://lists.sourceforge.net/lists/listinfo/xmldb-org-general |
From: Travis S. <Tra...@no...> - 2005-04-07 15:50:13
|
I have been tasked with modifying the XML:DB XAPI standard. I have been reading the lists to identify suggestions for evolving the standard. Some of which would require the API to be modified substantially. I need some help determining how I should approach suggestions which would require incompatible changes to the API. 1. Ignore the suggestions completely -- It is very important that the evolved API is compatible with the current API. 2. Case by case -- It would be nice to have the evolved API compatible with the current API, but we will accept some modification. 3. Lessons learned -- We will accept major modifications to the evolved API. -Trav |
From: Per N. <per...@us...> - 2005-03-18 09:39:42
|
Hi Travis, onsdagen den 16 mars 2005 18.26 skrev Travis Stevens: > I would like to address the relationship of the XAPI with the > Xinclude[1] specification. XInclude is a specification for merging XML > documents. The basic example is including an XML document at a given URL. > > <?xml version='1.0'?> > <document xmlns:xi="http://www.w3.org/2001/XInclude"> > <p>120 Mz is adequate for an average home user.</p> > <xi:include href="disclaimer.xml"/> > </document> > > One should be able to specify a resource in an XML:DB database in a > standard way. A simple idea would be to reference the resource by ID: > <xi:include > href="xmldb:vendorx://db.xmlmovies.com:2030/movies?resourceId=5" />. Looks good to me. > Should xpath and xquery also be allowed as part of the URI? XQuery is not yet fully integrated in the API. I did an intial attempt heavily inspired by the eXists implementaiton but there is no reference implementation yet and the whole thing needs some refinement before it is ready. I think we need to finalize how XQuery works with the API before extending your basic idea of referencing a' la xinclude to also include xquery. I see nothing bad with allowing xpath expressions as part of the URI though. Best regards, Per > > Of course the XML parser would have to know how to handle the > xmldb:vendorx protocol, but that is a different issue. Also, > standardizing the relationship to XInclude would be orthogonal to > standardizing a possible REST syntax. > > Any thoughts? > > -Trav > > [1] http://www.w3.org/TR/xinclude/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Xmldb-org-general mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmldb-org-general |
From: Per N. <per...@us...> - 2005-03-18 09:15:09
|
Hi Travis, With one +1 vote (mine) and no objections I interpret this to mean that the XML:DB intiative is in favor of welcoming you as a committer on the project. I have now added you as such. Welcome on-board! Best regards, Per tisdagen den 15 mars 2005 23.04 skrev Per Nyfelt: > Hi Travis, > > This sounds really good. We are in great need of resources. Taking the lead > and moving forward with the next version of the XML:DB API is long overdue > and would be very much appreciated. The mail list archive has some > discussions about suggested changes. If this what you had in mind please > let us know your thoughts on this matter and also let me know your > SourceForge id so I can give you the nessesary rights to CVS (unless > someone else objects that is). > > Best regards, > Per > > tisdagen den 15 mars 2005 18.26 skrev Travis Stevens: > > I am interested in volunteering some time in improving this project. I > > have been involved with the XAPI for about a year. I managed to > > implement the XAPI as a wrapper to a proprietary database and I have > > also written a SOAP implementation in which the client XAPI > > transparently uses SOAP to communicate with a remote XAPI wrapped in a > > SOAP service. > > > > -Trav > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Xmldb-org-general mailing list > > Xml...@li... > > https://lists.sourceforge.net/lists/listinfo/xmldb-org-general > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Xmldb-org-general mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmldb-org-general |
From: Per N. <per...@us...> - 2005-03-16 20:56:40
|
OK, great! onsdagen den 16 mars 2005 18.06 skrev Travis Stevens: > >This sounds really good. We are in great need of resources. Taking the > > lead and moving forward with the next version of the XML:DB API is long > > overdue and would be very much appreciated. The mail list archive has > > some discussions about suggested changes. > > I will organize the suggested changes provided in the mail list archive > and post the issues for feedback and voting sometime next week. > -Trav > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Xmldb-org-general mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmldb-org-general |
From: Travis S. <Tra...@no...> - 2005-03-16 17:26:32
|
I would like to address the relationship of the XAPI with the Xinclude[1] specification. XInclude is a specification for merging XML documents. The basic example is including an XML document at a given URL. <?xml version='1.0'?> <document xmlns:xi="http://www.w3.org/2001/XInclude"> <p>120 Mz is adequate for an average home user.</p> <xi:include href="disclaimer.xml"/> </document> One should be able to specify a resource in an XML:DB database in a standard way. A simple idea would be to reference the resource by ID: <xi:include href="xmldb:vendorx://db.xmlmovies.com:2030/movies?resourceId=5" />. Should xpath and xquery also be allowed as part of the URI? Of course the XML parser would have to know how to handle the xmldb:vendorx protocol, but that is a different issue. Also, standardizing the relationship to XInclude would be orthogonal to standardizing a possible REST syntax. Any thoughts? -Trav [1] http://www.w3.org/TR/xinclude/ |
From: Travis S. <Tra...@no...> - 2005-03-16 17:07:01
|
>This sounds really good. We are in great need of resources. Taking the lead >and moving forward with the next version of the XML:DB API is long overdue >and would be very much appreciated. The mail list archive has some >discussions about suggested changes. > I will organize the suggested changes provided in the mail list archive and post the issues for feedback and voting sometime next week. -Trav |