On Fri, Mar 23, 2012 at 10:52 AM, Michał Jaskurzyński <[email protected]>wrote:
> What do you think about this projekt: > http://wi.wu.ac.at/rgf/diplomarbeiten/#bakk_201203a ? Is it > sufficient? Should ODF Command Line Tools be closed or should use this > bachelor paper and extend it? > > Hi Michal, I have not had time to read the entire paper, but I did browse through it, especially the code samples. It looks like it is a REXX wrapper of the ODF Toolkit, with an abstraction level similar to our Simple API. There are other ODF libraries out there as well, for other languages, such as: python: http://pypi.python.org/pypi/lpod-python perl: http://search.cpan.org/~jmgdoc/OpenOffice-OODoc/ These are useful, but I don't think it satisfies the exact same need as the command line tools would. I think it is the difference between document manipulation and text processing. We have a variety of tools that operate on plain, ASCII text, from grep, diff, sed, awk, sort, uniq, cat, etc. These are doing simple text processing, but doing it in a way that more powerful tool chains can be build from them. A scripting language that allows manipulation of ODF documents is good. But it is still at a lower level. It offers get/set methods for content at a fine-grained level. But where are the more complex text processing actions? Of course, you could build the more complex operations on top of a scripting wrapper. So these approaches are complementary. Btw, I added some more info to the idea document: https://issues.apache.org/jira/browse/ODFTOOLKIT-308 -Rob > WBR > Michal > > 2012/3/21 Rob Weir <[email protected]>: > > On Wed, Mar 21, 2012 at 10:34 AM, Michał Jaskurzyński > > <[email protected]> wrote: > >> I would like to use JavaCC Parser Generator for parsing scripts. What > >> do you think about that? Are there any obstacles that I don't know? > >> > > > > In general, the use of 3rd party code in Apache projects is allowed, > > provided we have access to the code under a compatible open source > > license. > > > > The thing to check is whether JavaCC puts any restrictions on the > > generated code. Some "compiler compilers" (like early versions of > > Bison) put a copyleft license on generated code. This would not be > > compatible with the Apache license. > > > > Looking at JavaCC we see this license: > > > > "Copyright (c) 2006, Sun Microsystems, Inc. > > All rights reserved. > > > > Redistribution and use in source and binary forms, with or without > > modification, are permitted provided that the following conditions are > met: > > > > * Redistributions of source code must retain the above copyright > notice, > > this list of conditions and the following disclaimer. > > * Redistributions in binary form must reproduce the above copyright > > notice, this list of conditions and the following disclaimer in the > > documentation and/or other materials provided with the distribution. > > * Neither the name of the Sun Microsystems, Inc. nor the names of its > > contributors may be used to endorse or promote products derived from > > this software without specific prior written permission. > > > > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS > IS" > > AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > > ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > > LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > > CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > > SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > > INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > > CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > > ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > > THE POSSIBILITY OF SUCH DAMAGE." > > > > So I think this will be OK. From a technical perspective, I think > > this is a good way to go, especially if this evolves into an > > interpreted document processing language. > > > > -Rob > > > >> WBR > >> Michal >
