From: Antoni M. <ant...@df...> - 2006-11-28 18:01:19
|
After two weeks of learning, researching and programming, I am pleased to present the OSGI incarnation of Aperture... What is done: * 6 'Middle-grained' Bundles: * 1. Core services 2. Supporting services 3. Vocabulary 4. Util 5. Core implementations 6. Supporting implementations * 2. 'Coarse-grained' bundles * 1. Core ( 1-4 taken together ) 2. Impl ( 5-6 taken together ) 52 Activators - Service activators - register a service (e.g. Extractor Registry). Use a service tracker to detect all incoming factories. If factories thisappear, they are also automatically unregistered. This assumes that every factory registers an osgi service on it's own under the generic name of an interface (e.g. org.semanticdesktop.aperture.accessor.DataAccessorFactory). - Implementation activators. Register factories as OSGI services (which are in turn detected by registries). The activators are chained one for every 'elementary' bundle. There is a set of broader activators, that simply start and stop appropriate elementary activators. Activators are stored in a separate directory. Build infrastructure * build.xml - Is more than 1000 lines longer than it used to be. Every 'elementary' bundle has it's own selector. It selects the source the generated classes, all resources and libraries needed by every elementary bundle. Every 'elementary' selector could potentially be used as a basis for an 'elementary' jar file. (If we wanted to split aperture into 40 bundles). * 8 manifest files. Only two actually work. I didn't manage to persuade mangen into doing what I wanted it to do. I wrote them by myself. Mangen is disabled in the build script and could safely be deleted from the CVS. The necessity to determine the required bundles, imports and exports manually took too much time. I haven't managed to make the six 'middle-grained' bundles work. I disabled their creation in the build script. They can easily be re-enabled. We could use eclipse PDE. Every bundle could be a separate project that imports source files from the aperture directory (with the help of the eclipse include/exclude facility). We would loose the possibility of automatic builds though. It wouldn't solve the problem of having to maintain 40 manifests either. This is the only problem. Conclusion: If you really think about dividing aperture into the smallest possible units, some kind of automatic manifest-generating facility is necessary. Issues: I moved the MailUtil class from the util package because it would introduce a dependency on mail....jar for the core bundle All classes from the core bundle that refer directly to org.openrdf will not work (that is: RepositoryUtil, RepositoryAccessData etc.) This would introduce a dependency on sesame. The ResourceUtil methods got a second argument (that is a class that originates the request). It didn't work under OSGI since every bundle has it's own classloader and the resource lookup wouldn't work. 7. Added an OutlookAccessorFactory ------------------------------------------------------------------------- EXAMPLE: I've written a simple example of the FileSystemCrawler. It doesn't have any interface (yet...) the path to the root directory and to the repository file is hard-coded in: src/examples/org/semanticdesktop/aperture/examples/osgi/ExampleFileCrawlerActivator.java line number 66. If you want to see it in action do the following: 1. download the 'distribution' from http://www.dfki.uni-kl.de/~mylka/aperture-20061128.zip. It contains two full-featured execution environments - Equinox and Knopflerfish. This example works under Equinox but fails under Knopflerfish. I have been unable to find out why. 2. Unpack it and edit the file mentioned above. 3. type 'ant osgi.dist' 4. Go to the directory build/dist/bundles 5. run the run.aperture.sh script (I did it on linux, it shouldn't be too difficult to adjust it to work under windows 6. When the osgi prompt appears, type 'ss' to show the list of bundles. There should be 10 started bundles and the 11'th one should be the aperture-example. 7. type start 11. The example will start to crawl the given directory and will store the rdf in the given file. (Hopefully) Any comments welcome Antoni Mylka ant...@dk... |
From: Leo S. <leo...@df...> - 2006-11-29 09:49:44
|
very good! could you copy your text into the /doc/ folder, in some html about OSGIaperturte and link to it from the main doc page? we can then update the doc on the sf website. best Leo Es begab sich aber da Antoni Mylka zur rechten Zeit 28.11.2006 19:01 folgendes schrieb: > After two weeks of learning, researching and programming, I am pleased > to present the OSGI incarnation of Aperture... > > What is done: > > * 6 'Middle-grained' Bundles: * > > 1. Core services > 2. Supporting services > 3. Vocabulary > 4. Util > 5. Core implementations > 6. Supporting implementations > > * 2. 'Coarse-grained' bundles * > > 1. Core ( 1-4 taken together ) > 2. Impl ( 5-6 taken together ) > > 52 Activators > - Service activators - register a service (e.g. Extractor Registry). Use > a service tracker to detect all incoming factories. If factories > thisappear, they are also automatically unregistered. This assumes that > every factory registers an osgi service on it's own under the generic > name of an interface (e.g. > org.semanticdesktop.aperture.accessor.DataAccessorFactory). > > - Implementation activators. Register factories as OSGI services (which > are in turn detected by registries). > > The activators are chained one for every 'elementary' bundle. There > is a set of broader activators, that simply start and stop appropriate > elementary activators. > > Activators are stored in a separate directory. > > Build infrastructure > * build.xml - Is more than 1000 lines longer than it used to be. Every > 'elementary' bundle has it's own selector. It selects the source > the generated classes, all resources and libraries needed by every > elementary bundle. Every 'elementary' selector could potentially be > used as a basis for an 'elementary' jar file. (If we wanted to split > aperture into 40 bundles). > * 8 manifest files. Only two actually work. I didn't manage to persuade > mangen into doing what I wanted it to do. I wrote them by myself. > Mangen is disabled in the build script and could safely be deleted > from the CVS. The necessity to determine the required bundles, > imports and exports manually took too much time. I haven't managed > to make the six 'middle-grained' bundles work. I disabled their > creation in the build script. They can easily be re-enabled. > > We could use eclipse PDE. Every bundle could be a separate project that > imports source files from the aperture directory (with the help of the > eclipse include/exclude facility). We would loose the possibility of > automatic builds though. It wouldn't solve the problem of having to > maintain 40 manifests either. This is the only problem. > > Conclusion: > > If you really think about dividing aperture into the smallest possible > units, some kind of automatic manifest-generating facility is necessary. > > Issues: > > I moved the MailUtil class from the util package because it would > introduce a dependency on mail....jar for the core bundle > > All classes from the core bundle that refer directly to org.openrdf > will not work (that is: RepositoryUtil, RepositoryAccessData etc.) This > would introduce a dependency on sesame. > > The ResourceUtil methods got a second argument (that is a class that > originates the request). It didn't work under OSGI since every bundle > has it's own classloader and the resource lookup wouldn't work. > > 7. Added an OutlookAccessorFactory > > ------------------------------------------------------------------------- > > EXAMPLE: > > I've written a simple example of the FileSystemCrawler. It doesn't have > any interface (yet...) the path to the root directory and to the > repository file is hard-coded in: > > src/examples/org/semanticdesktop/aperture/examples/osgi/ExampleFileCrawlerActivator.java > > line number 66. > > If you want to see it in action do the following: > > 1. download the 'distribution' from > http://www.dfki.uni-kl.de/~mylka/aperture-20061128.zip. It contains two > full-featured execution environments - Equinox and Knopflerfish. This > example works under Equinox but fails under Knopflerfish. I have been > unable to find out why. > > 2. Unpack it and edit the file mentioned above. > 3. type 'ant osgi.dist' > 4. Go to the directory build/dist/bundles > 5. run the run.aperture.sh script (I did it on linux, it shouldn't be > too difficult to adjust it to work under windows > 6. When the osgi prompt appears, type 'ss' to show the list of bundles. > There should be 10 started bundles and the 11'th one should be the > aperture-example. > 7. type start 11. The example will start to crawl the given directory > and will store the rdf in the given file. (Hopefully) > > Any comments welcome > > Antoni Mylka > ant...@dk... > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann DFKI GmbH P.O. Box 2080 Fon: +49 631 205-3503 67608 Kaiserslautern Fax: +49 631 205-3472 Germany Mail: leo...@df... ____________________________________________________ |
From: Antoni M. <ant...@df...> - 2006-11-29 18:45:34
|
Leo Sauermann napisa=C5=82(a): > very good! >=20 > could you copy your text into the /doc/ folder, in some html about=20 > OSGIaperturte > and link to it from the main doc page? >=20 > we can then update the doc on the sf website. >=20 > best > Leo >=20 I've written a text. It is in the doc/tutorial/osgi.html. Publishing it=20 on the website would not be a good idea, since it refers to the CVS=20 snapshot, not the current release. If we were to make a new release before christmas, entire documentation=20 would need to be reworked, some note about RDF2Go should be added,=20 examples should be rewritten. It would also be a good oportunity to=20 convert the docs to some more generic format (Latex, Docbook, whatever)=20 to make it possible to generate nice-looking HTML and PDF versions. Antoni Mylka ant...@df... |
From: Leo S. <leo...@df...> - 2006-12-04 08:49:27
|
Hi Guys, looking at our workload at DFKI (Nepomuk's first deliverables are due=20 12/2006), I think a release would be too much now. end of january? Btw: does anyone (Jack?) have time to make a bibtex datasource and crawle= r? doc: the sesame guys use docbook XML to create their docs, maybe we should=20 use that. I don't fancy these systems very much, html and a good CSS should do it, but surely docbook is better than nothing. we can give it a try .. when? best Leo Es begab sich aber da Antoni Mylka zur rechten Zeit 29.11.2006 19:45=20 folgendes schrieb: > Leo Sauermann napisa=C5=82(a): > =20 >> very good! >> >> could you copy your text into the /doc/ folder, in some html about=20 >> OSGIaperturte >> and link to it from the main doc page? >> >> we can then update the doc on the sf website. >> >> best >> Leo >> >> =20 > > I've written a text. It is in the doc/tutorial/osgi.html. Publishing it= =20 > on the website would not be a good idea, since it refers to the CVS=20 > snapshot, not the current release. > > If we were to make a new release before christmas, entire documentation= =20 > would need to be reworked, some note about RDF2Go should be added,=20 > examples should be rewritten. It would also be a good oportunity to=20 > convert the docs to some more generic format (Latex, Docbook, whatever)= =20 > to make it possible to generate nice-looking HTML and PDF versions. > > Antoni Mylka > ant...@df... > > -----------------------------------------------------------------------= -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share= your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > > =20 --=20 ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann=20 DFKI GmbH P.O. Box 2080 Fon: +49 631 205-3503 67608 Kaiserslautern Fax: +49 631 205-3472 Germany Mail: leo...@df... ____________________________________________________ |
From: Jack P. <jac...@sr...> - 2006-12-05 01:59:42
|
Jack (c'est moi) will be out of the country over much of December and swamped when he gets back. Not too much chance of contributing a bibtex datasource anytime soon, but would love to do so later if it's not satisfied yet. My own comment is that, while I don't want to start a flame war, I have this intuition that the XML format in Open Office might be a better XML to persist to than would be OpenDoc. That format just went ISO standard. I am not saying OpenDoc is inadequate. I will say that it has been really tough finding a decent editor for it; all of the OpenIRIS documents were formatted in OpenDoc and the apache fop project, which we used, is buggy, needed patching, and is also nolonger developed. I'd much rather just use OpenOffice to do this kind of work. Perhaps an OO template for biblio representations either exists or could be created. Just a half EURO... Cheers Jack Leo Sauermann wrote: > Hi Guys, > > looking at our workload at DFKI (Nepomuk's first deliverables are due > 12/2006), > I think a release would be too much now. > end of january? > > Btw: does anyone (Jack?) have time to make a bibtex datasource and crawler? > > doc: > the sesame guys use docbook XML to create their docs, maybe we should > use that. > I don't fancy these systems very much, html and a good CSS should do it, > but surely docbook is better than nothing. > we can give it a try .. when? > > best > Leo > > Es begab sich aber da Antoni Mylka zur rechten Zeit 29.11.2006 19:45 > folgendes schrieb: >> Leo Sauermann napisał(a): >> >>> very good! >>> >>> could you copy your text into the /doc/ folder, in some html about >>> OSGIaperturte >>> and link to it from the main doc page? >>> >>> we can then update the doc on the sf website. >>> >>> best >>> Leo >>> >>> >> >> I've written a text. It is in the doc/tutorial/osgi.html. Publishing it >> on the website would not be a good idea, since it refers to the CVS >> snapshot, not the current release. >> >> If we were to make a new release before christmas, entire documentation >> would need to be reworked, some note about RDF2Go should be added, >> examples should be rewritten. It would also be a good oportunity to >> convert the docs to some more generic format (Latex, Docbook, whatever) >> to make it possible to generate nice-looking HTML and PDF versions. >> >> Antoni Mylka >> ant...@df... >> > > -- > ____________________________________________________ > DI Leo Sauermann http://www.dfki.de/~sauermann > DFKI GmbH > P.O. Box 2080 Fon: +49 631 205-3503 > 67608 Kaiserslautern Fax: +49 631 205-3472 > Germany Mail: leo...@df... > ____________________________________________________ > > |
From: Christiaan F. <chr...@ad...> - 2006-12-05 08:25:23
|
Jack Park wrote: > My own comment is that, while I don't want to start a flame war, I have > this intuition that the XML format in Open Office might be a better XML > to persist to than would be OpenDoc. That format just went ISO standard. > I am not saying OpenDoc is inadequate. I will say that it has been > really tough finding a decent editor for it; all of the OpenIRIS > documents were formatted in OpenDoc and the apache fop project, which we > used, is buggy, needed patching, and is also nolonger developed. I'd > much rather just use OpenOffice to do this kind of work. Perhaps an OO > template for biblio representations either exists or could be created. I don't see your point exactly but perhaps I misunderstood. First of all, does your comment relate to Leo's question about a bibtex crawler of to the choice for a documentation framework? I assume it's the latter but as you refer to "biblio representations" at the end, I got confused. With "the XML format in Open Office" you mean the older XML-based formats used by OpenOffice 1.x? As OpenDocument is the primary document format of OpenOffice 2.x, why not use that? Besides OpenOffice there are other editors available for it as well and since it has been standardized, I would expect that in the end more tools will support OpenDocument than the older format. Chris -- |
From: Leo S. <leo...@df...> - 2006-12-05 13:33:04
|
the question was on DOC - documentation and I suggested to do the same as the sesames with docbook XML and Jack said that they had problems with opendoc (don't know what that is) and that open office is better. true - I don't know of any editor for the docbook xml :-| we search for something to write docs Es begab sich aber da Christiaan Fluit zur rechten Zeit 05.12.2006 09:25 folgendes schrieb: > Jack Park wrote: > >> My own comment is that, while I don't want to start a flame war, I have >> this intuition that the XML format in Open Office might be a better XML >> to persist to than would be OpenDoc. That format just went ISO standard. >> I am not saying OpenDoc is inadequate. I will say that it has been >> really tough finding a decent editor for it; all of the OpenIRIS >> documents were formatted in OpenDoc and the apache fop project, which we >> used, is buggy, needed patching, and is also nolonger developed. I'd >> much rather just use OpenOffice to do this kind of work. Perhaps an OO >> template for biblio representations either exists or could be created. >> > > I don't see your point exactly but perhaps I misunderstood. > > First of all, does your comment relate to Leo's question about a bibtex > crawler of to the choice for a documentation framework? I assume it's > the latter but as you refer to "biblio representations" at the end, I > got confused. > > With "the XML format in Open Office" you mean the older XML-based > formats used by OpenOffice 1.x? As OpenDocument is the primary document > format of OpenOffice 2.x, why not use that? Besides OpenOffice there are > other editors available for it as well and since it has been > standardized, I would expect that in the end more tools will support > OpenDocument than the older format. > > > Chris > -- > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann DFKI GmbH P.O. Box 2080 Fon: +49 631 205-3503 67608 Kaiserslautern Fax: +49 631 205-3472 Germany Mail: leo...@df... ____________________________________________________ |
From: Jack P. <jac...@sr...> - 2006-12-05 14:15:56
|
The problems with opendoc have been that it is undersupported in Java. the apache FOP project seems dead, not developed in a long time (though it might have picked up in the last year; I haven't checked in a long time). OpenDoc, itself, is a well-supported and even popular product. I simply think it is time to move on to something that is much larger in scope yet still satisfies the same need as OpenDoc. At least you can use OpenOffice to edit it, eventually even MS Word (it says here). Jack Leo Sauermann wrote: > > the question was on DOC - documentation > and I suggested to do the same as the sesames with docbook XML > > and Jack said that they had problems with opendoc (don't know what that > is) and that open office is better. > > true - I don't know of any editor for the docbook xml :-| > > we search for something to write docs > > Es begab sich aber da Christiaan Fluit zur rechten Zeit 05.12.2006 09:25 > folgendes schrieb: >> Jack Park wrote: >> >>> My own comment is that, while I don't want to start a flame war, I have >>> this intuition that the XML format in Open Office might be a better XML >>> to persist to than would be OpenDoc. That format just went ISO standard. >>> I am not saying OpenDoc is inadequate. I will say that it has been >>> really tough finding a decent editor for it; all of the OpenIRIS >>> documents were formatted in OpenDoc and the apache fop project, which we >>> used, is buggy, needed patching, and is also nolonger developed. I'd >>> much rather just use OpenOffice to do this kind of work. Perhaps an OO >>> template for biblio representations either exists or could be created. >>> >> >> I don't see your point exactly but perhaps I misunderstood. >> >> First of all, does your comment relate to Leo's question about a bibtex >> crawler of to the choice for a documentation framework? I assume it's >> the latter but as you refer to "biblio representations" at the end, I >> got confused. >> >> With "the XML format in Open Office" you mean the older XML-based >> formats used by OpenOffice 1.x? As OpenDocument is the primary document >> format of OpenOffice 2.x, why not use that? Besides OpenOffice there are >> other editors available for it as well and since it has been >> standardized, I would expect that in the end more tools will support >> OpenDocument than the older format. >> >> >> Chris >> -- >> |
From: Leo S. <leo...@df...> - 2006-12-06 08:55:06
|
Hi All, to be more "uri-centered", here is the opendocument we are talking about: http://en.wikipedia.org/wiki/OpenDocument NOT to be mixed with the deprecated Xerox/Apple opendoc (Jack, watch your words!) http://en.wikipedia.org/wiki/OpenDoc Antoni, next year when we have more oxygen here to breath, could you look at OpenOffice 2.x and see if anybody else on the planet uses opendocument / .odt files to write Software documentation? if yes, I see no problem also doing it. The clear advantage is availability of a good editor (openoffice) and the possibility that other people may write converters for HTML output. best Leo Es begab sich aber da Jack Park zur rechten Zeit 05.12.2006 15:15 folgendes schrieb: > The problems with opendoc have been that it is undersupported in Java. > the apache FOP project seems dead, not developed in a long time (though > it might have picked up in the last year; I haven't checked in a long > time). OpenDoc, itself, is a well-supported and even popular product. I > simply think it is time to move on to something that is much larger in > scope yet still satisfies the same need as OpenDoc. At least you can use > OpenOffice to edit it, eventually even MS Word (it says here). > > Jack > > Leo Sauermann wrote: > >> the question was on DOC - documentation >> and I suggested to do the same as the sesames with docbook XML >> >> and Jack said that they had problems with opendoc (don't know what that >> is) and that open office is better. >> >> true - I don't know of any editor for the docbook xml :-| >> >> we search for something to write docs >> >> Es begab sich aber da Christiaan Fluit zur rechten Zeit 05.12.2006 09:25 >> folgendes schrieb: >> >>> Jack Park wrote: >>> >>> >>>> My own comment is that, while I don't want to start a flame war, I have >>>> this intuition that the XML format in Open Office might be a better XML >>>> to persist to than would be OpenDoc. That format just went ISO standard. >>>> I am not saying OpenDoc is inadequate. I will say that it has been >>>> really tough finding a decent editor for it; all of the OpenIRIS >>>> documents were formatted in OpenDoc and the apache fop project, which we >>>> used, is buggy, needed patching, and is also nolonger developed. I'd >>>> much rather just use OpenOffice to do this kind of work. Perhaps an OO >>>> template for biblio representations either exists or could be created. >>>> >>>> >>> I don't see your point exactly but perhaps I misunderstood. >>> >>> First of all, does your comment relate to Leo's question about a bibtex >>> crawler of to the choice for a documentation framework? I assume it's >>> the latter but as you refer to "biblio representations" at the end, I >>> got confused. >>> >>> With "the XML format in Open Office" you mean the older XML-based >>> formats used by OpenOffice 1.x? As OpenDocument is the primary document >>> format of OpenOffice 2.x, why not use that? Besides OpenOffice there are >>> other editors available for it as well and since it has been >>> standardized, I would expect that in the end more tools will support >>> OpenDocument than the older format. >>> >>> >>> Chris >>> -- >>> >>> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann DFKI GmbH P.O. Box 2080 Fon: +49 631 205-3503 67608 Kaiserslautern Fax: +49 631 205-3472 Germany Mail: leo...@df... ____________________________________________________ |
From: Christiaan F. <chr...@ad...> - 2006-12-06 10:19:28
|
Leo Sauermann wrote: > next year when we have more oxygen here to breath, > could you look at OpenOffice 2.x and see if anybody else on the planet > uses opendocument / .odt files to write Software documentation? We do :) Whenever you see us use something else, it's probably because we haven't ported it to OpenDocument yet. When asking Arjohn about the use of Docbook for Sesame he noted that he would now also consider using OpenDocument if he had to do it all over again. But truth be told, so far we have only used it to generate PDFs of our documentation. Docbook has facilities for exporting to several HTML-based formats (e.g. all in 1 file, split across multiple files with fancy tables of contents, etc.). I don't know whether there are any tools that can do the same for OpenDocument or whether OpenOffice can do that. > if yes, I see no problem also doing it. > The clear advantage is availability of a good editor (openoffice) This I really like, so I would be in favor of OpenDocument. Chris -- |
From: Jack P. <jac...@sr...> - 2006-12-06 16:18:37
|
My bad. When I said "opendoc" (perhaps a wisp of wishful thinking that Apple's opendoc still lives), I meant DocBook. You can turn the lights back on now... Jack Leo Sauermann wrote: > Hi All, > > to be more "uri-centered", here is the opendocument we are talking about: > http://en.wikipedia.org/wiki/OpenDocument > > NOT to be mixed with the deprecated Xerox/Apple opendoc (Jack, watch > your words!) > http://en.wikipedia.org/wiki/OpenDoc > > Antoni, > next year when we have more oxygen here to breath, > could you look at OpenOffice 2.x and see if anybody else on the planet > uses opendocument / .odt files to write Software documentation? > if yes, I see no problem also doing it. > The clear advantage is availability of a good editor (openoffice) and > the possibility that other people may write converters for HTML output. > > best > Leo > > Es begab sich aber da Jack Park zur rechten Zeit 05.12.2006 15:15 > folgendes schrieb: >> The problems with opendoc have been that it is undersupported in Java. >> the apache FOP project seems dead, not developed in a long time (though >> it might have picked up in the last year; I haven't checked in a long >> time). OpenDoc, itself, is a well-supported and even popular product. I >> simply think it is time to move on to something that is much larger in >> scope yet still satisfies the same need as OpenDoc. At least you can use >> OpenOffice to edit it, eventually even MS Word (it says here). >> >> Jack >> >> Leo Sauermann wrote: >> >>> the question was on DOC - documentation >>> and I suggested to do the same as the sesames with docbook XML >>> >>> and Jack said that they had problems with opendoc (don't know what that >>> is) and that open office is better. >>> >>> true - I don't know of any editor for the docbook xml :-| >>> >>> we search for something to write docs >>> >>> Es begab sich aber da Christiaan Fluit zur rechten Zeit 05.12.2006 09:25 >>> folgendes schrieb: >>> >>>> Jack Park wrote: >>>> >>>> >>>>> My own comment is that, while I don't want to start a flame war, I have >>>>> this intuition that the XML format in Open Office might be a better XML >>>>> to persist to than would be OpenDoc. That format just went ISO standard. >>>>> I am not saying OpenDoc is inadequate. I will say that it has been >>>>> really tough finding a decent editor for it; all of the OpenIRIS >>>>> documents were formatted in OpenDoc and the apache fop project, which we >>>>> used, is buggy, needed patching, and is also nolonger developed. I'd >>>>> much rather just use OpenOffice to do this kind of work. Perhaps an OO >>>>> template for biblio representations either exists or could be created. >>>>> >>>>> >>>> I don't see your point exactly but perhaps I misunderstood. >>>> >>>> First of all, does your comment relate to Leo's question about a bibtex >>>> crawler of to the choice for a documentation framework? I assume it's >>>> the latter but as you refer to "biblio representations" at the end, I >>>> got confused. >>>> >>>> With "the XML format in Open Office" you mean the older XML-based >>>> formats used by OpenOffice 1.x? As OpenDocument is the primary document >>>> format of OpenOffice 2.x, why not use that? Besides OpenOffice there are >>>> other editors available for it as well and since it has been >>>> standardized, I would expect that in the end more tools will support >>>> OpenDocument than the older format. >>>> >>>> >>>> Chris >>>> -- >>>> |