Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ANNOUNCE: tDOM 0.9.1

211 views
Skip to first unread message

Rolf Ade

unread,
Jul 25, 2018, 7:01:28 PM7/25/18
to

It's a good point to roll out what's done before other changes took
place, so: tDOM 0.9.1 got tagged, source balls and windows binaries
are available. Find them at

http://tdom.org/downloads/

or see the README below for more information.

The most notable changes since the last release are:

- The included expat is now 2.2.5, the most recent expat release.

- An interface to use expat as pull parser (StAX like).

- Some minor options for more control about parsing ([dom parse
-keepCDATA]) and serialization (asXML -nogtescape
--noEmptyElementTag).

- A few bug fixes important to whom are bitten by them.

And other things.

See the file CHANGES in the root of the source tree or
http://tdom.org/index.html/artifact/014245dd36bb67aa for a more
detailed list or http://tdom.org/index.html/timeline for even more
details.

Thanks to the contributors and all the others for help, encouragement
and discussion.

rolf

The README follows:


tDOM - a XML/DOM/XPath/XSLT/HTML/JSON implementation for Tcl
(Version 0.9.1)


This directory contains a freely distributable thread-safe extension
to Tcl/Tk called tDOM.

tDOM contains:

* for convenience expat 2.2.5, the XML parser originated from
James Clark, although you're able to link tDOM with other
expat versions or the library provided by the system.

* building a DOM tree from XML in one go implemented in C for
maximum performance and minimum memory usage, and DOM I and II
methods to work on such a tree using either a OO-like or a
handle syntax.

* a Tcl interface to expat for event-like (SAX-like) XML parsing.

* a complete, compliant and fast XPath implementation in C
following the November 99 W3C recommendation for navigating and
data extraction.

* a fast XSLT implementation in C following the W3C Recommendation
16 November 1999.

* optional DTD validation.

* a JSON parser which parses any possible JSON input into a DOM
tree without losing information.

* an efficient and Tcl'ish way to create XML and HTML documents
and JSON string.

* as build option an interface to the gumbo HTML5 parser, which
also digests almost any other HTML.

* an even faster simple XML parser for trusted XML input.

* A slim Tcl interface to use expat as pull-parser.

* additional convenience methods.

* and more.


DOCUMENTATION

The documentation is included into the source distribution in HTML
and man format. Alternatively, read it online starting at
http://tdom.org/index.html/doc/trunk/doc/index.html


GETTING THE CODE

The development repository is hosted at http://tdom.org and is
mirrored at http://core.tcl.tk/tdom. You are encouraged to use
trunk.

If you insist on using an older tDOM with lesser features and
probably more bugs, you should use the latest release 0.9.1. Get
the source code release from
http://tdom.org/downloads/tdom-0.9.1-src.tgz or
http://tdom.org/downloads/tdom-0.9.1-src.zip

Windows binaries (32 bit as well as 64 bit) of the 0.9.1 release
are also available. Get it from
http://tdom.org/downloads/tdom-0.9.1-windows-x64.zip and
http://tdom.org/downloads/tdom-0.9.1-windows-x86.zip

The provided windows binaries include (statically linked) the
HTML5 parser.


COMPILING tDOM

Depending on your platform (unix/mac or win), go to the
corresponding directory and invoke the configure script:

../configure
make
make test
make install

Alternatively, you can build the tDOM package in just about any
directory elsewhere on the fileystem (since TEA-compatible).

You might also want to do "../configure --help" to get a list of
all supported options of the configure script. In the "unix"
directory there is a "CONFIG" file containing some examples on how
to invoke the "configure" script for some common cases. You can
peek there. This file also includes a short description of the
tDOM specific configure options.

Since tDOM is TEA-compatible you should be able to build it using
the MinGW build environment for Windows. There is also the MSVC
nmake file so you can compile the package with Microsoft tools.
Refer to the README in the win directory for more details about
building on Windows.

The compile process will build the tDOM shared library suitable for
loading into the Tcl shell using standard "package require" mechanism.


REPORTING BUGS

Please head to http://tdom.org/index.html/ticket and click on "New
Ticket". Log in as anonymous and report your findings. If you
prefer to have an individual login write Rolf a mail.


HISTORY

tDOM was started by Jochen Loewer (loe...@hotmail.com) and
developed by Jochen and Rolf Ade (ro...@pointsman.de) with
contributions by Zoran Vasiljevic (z...@archiware.com). Since more
than a dozen years it is maintained and developed by Rolf Ade.

phil...@gmail.com

unread,
Jul 25, 2018, 7:24:39 PM7/25/18
to
Hi,

Thanks for the update.

Is there any chance to have the license change to the more normal Tcl/Tk
BSD-ish license? We have trouble when using things that have other licenses.

If you prefer to stay with Mozilla, we have an easier time with the Mozilla 2.0 license than with Mozilla 1.1.

https://www.mozilla.org/en-US/MPL/2.0/

Rolf Ade

unread,
Jul 25, 2018, 8:25:11 PM7/25/18
to

phil...@gmail.com writes:
> Is there any chance to have the license change to the more normal Tcl/Tk
> BSD-ish license? We have trouble when using things that have other licenses.

What do you fear? That I sue you for using tDOM? Thats unlikely.

You ask if there is any chance. Well, it's probably not impossible, so -
sure there is one, what are you willing to do?

If this licenses fuss does mean something (and it surely does, otherwise
you wouldn't brought it up here, wouldn't you?) somebody has to
carefully study what does this mean for tDOM and what has to be done and
to do it.

I prefer to write code. (Or read. Or think. Hear. Meet people. Go
hiking.) Make it a bite-sized thing for me, present it in one go what's
needed, ensure me, that I can dump any legal trouble upon you if there
is something wrong with this change of lincens, well, I'll give in to
it, I don't really care, and if it is that worth to you.

Or is it that you don't really care and just want me to be the one you
can dump the legal burdon onto?

Brad Lanam

unread,
Jul 26, 2018, 7:56:16 AM7/26/18
to

phil...@gmail.com

unread,
Jul 27, 2018, 8:24:55 PM7/27/18
to
Hi Rolf and Brad

Thanks for the response.

I, like you, much prefer to develop software, or make music, or go listen to music, or walk... - my knees aren't up to hiking much these days - and not to worry about licenses.

Regarding the motivation - our corporate lawyers do not like one specific clause (8.2) in the Mozilla 1.1 license. As I understand it, the wording is problematic in that it might be interpreted that anyone using software under this license and participating in any sort of patent infringement lawsuit (perhaps entirely unrelated to the open source software in question) might allow someone to open a very fat and ugly legal can of worms. (Don't ask me to defend or justify this viewpoint - it is simply the concern that was stated to me as the reason that I can not use tDom.) I think it comes from the very long structure of the clause and frequent use of the word 'any' but, as I said before, I am not a lawyer and have not desire to be one.

As I understand it, this clause was substantially revised and simplified to close such loopholes under Mozilla 2.0 - at least my corporate overlords are willing for me to use software released under Mozilla 2.0.

Like I said above, I just want to write code and make sure that the lawyers and managers don't slap my hands for any reason (which currently means I can't use tDom).

Mozilla 1.1 wording:

8.2. If You initiate litigation by asserting a patent infringement claim (excluding declatory judgment actions) against Initial Developer or a Contributor (the Initial Developer or Contributor against whom You file such action is referred to as "Participant") alleging that:

such Participant's Contributor Version directly or indirectly infringes any patent, then any and all rights granted by such Participant to You under Sections 2.1 and/or 2.2 of this License shall, upon 60 days notice from Participant terminate prospectively, unless if within 60 days after receipt of notice You either: (i) agree in writing to pay Participant a mutually agreeable reasonable royalty for Your past and future use of Modifications made by such Participant, or (ii) withdraw Your litigation claim with respect to the Contributor Version against such Participant. If within 60 days of notice, a reasonable royalty and payment arrangement are not mutually agreed upon in writing by the parties or the litigation claim is not withdrawn, the rights granted by Participant to You under Sections 2.1 and/or 2.2 automatically terminate at the expiration of the 60 day notice period specified above.
any software, hardware, or device, other than such Participant's Contributor Version, directly or indirectly infringes any patent, then any rights granted to You by such Participant under Sections 2.1(b) and 2.2(b) are revoked effective as of the date You first made, used, sold, distributed, or had made, Modifications made by that Participant.

Mozilla 2.0 wording for a similar clause:

5.2. If You initiate litigation against any entity by asserting a patent infringement claim (excluding declaratory judgment actions, counter-claims, and cross-claims) alleging that a Contributor Version directly or indirectly infringes any patent, then the rights granted to You by any and all Contributors for the Covered Software under Section 2.1 of this License shall terminate.

stefan

unread,
Aug 8, 2018, 5:19:42 AM8/8/18
to
> Regarding the motivation - our corporate lawyers do not like one specific clause (8.2) in the Mozilla 1.1 license.

That is the retaliation clause, right? Retaliation meaning that a contributor (!) suing other contributors for patent infringement loses all rights granted under the license, automatically. Well, a common understanding is that this affects contributors to the piece of software (not necessarily users of binaries); but once you have obtained a code base to build it from scratch, this becomes a gray zone. But MPL 2.0 is not only about a simplified/ clarified retaliation clause, it also makes a code base more compatible for contributions based on otherwise licensed contributions (Apache). MPL 2.0 licensed software can also be distributed along with GPL/LPGL software, which is just a win for tDOM.

https://www.mozilla.org/en-US/MPL/2.0/Revision-FAQ/#what-has-changed

> Make it a bite-sized thing for me, present it in one go what's
> needed, ensure me, that I can dump any legal trouble upon you if there
>is something wrong with this change of license, well, I'll give in to
> it, I don't really care, and if it is that worth to you.

Rolf, there is nothing to fear when going from 1.1 to 2.0, in my understanding. It just helps clarify issues and improves compatibility with other license types. Given that 0.9.1 is out (under MPL 1.1), now upgrading to MPL 2.0 with your trunk version is maybe a good moment? Version upgrading is explicitly permitted, foreseen by MPL itself, just change the header and LICENSE body:

See item 6 in https://www.mozilla.org/en-US/MPL/2.0/Revision-FAQ/

Maybe Phil/Brian want to contribute a MPL-2.0 upgrade branch to the tDOM fossil repository, for your review, rather than spending time on bringing TclXML back from the dead?

Cheers, Stefan





Rolf Ade

unread,
Aug 8, 2018, 8:31:59 AM8/8/18
to

stefan <stefan....@wu.ac.at> writes:
>> Regarding the motivation - our corporate lawyers do not like one
>> specific clause (8.2) in the Mozilla 1.1 license.
>
> That is the retaliation clause, right? Retaliation meaning that a
> contributor (!) suing other contributors for patent infringement loses
> all rights granted under the license, automatically.

Interesting explanation. So, since so far no single line of code
contribution from Phil, Brian or any other of their company has reached
me (well, some additional messages only about this legal stuff did
reached me per PM) we're talking about something that - at least so far
- hardly coudn't matter for them, yes?

So, Phil et al., this could potentially only be a matter in the future
if you plan to contribute something to tDOM that is more than a few
single lines of code. I would probably much more enjoy a conversation
about contributions and technical matters than this topic. It also
surely would motivate me more to look how I could please you better with
the "issue" they brought up.

> [MPL] Version upgrading is explicitly permitted, foreseen by MPL itself,
> just change the header and LICENSE body:
>
> See item 6 in https://www.mozilla.org/en-US/MPL/2.0/Revision-FAQ/

Even more interesting. So, they are even now able to redistribute tDOM
under the terms of MPL 2.0 alongside with their software, yes?

So, what exactly is the problem?

phil...@gmail.com

unread,
Aug 8, 2018, 12:22:30 PM8/8/18
to
> Even more interesting. So, they are even now able to redistribute tDOM
> under the terms of MPL 2.0 alongside with their software, yes?

I have heard this morning from our corporate lawyers that they agree that we can distribute under the upgraded terms of MPL 2.0 even when the code is published under MPL 1.1, and so there isn't an issue at all now.

Sorry to have bothered everyone - I definitely owe you all a round of drinks at the next Tcl conference if you are there.

stefan

unread,
Aug 8, 2018, 5:06:22 PM8/8/18
to

> > Even more interesting. So, they are even now able to redistribute tDOM
> > under the terms of MPL 2.0 alongside with their software, yes?
>
> I have heard this morning from our corporate lawyers that they agree that we can distribute under the upgraded terms of MPL 2.0 even when the code is published under MPL 1.1, and so there isn't an issue at all now.
>

Yep, this is a benefit of the MPL even (which contains that version-upgrade clause). Others, like Apache, do not and, therefore, unmodified re-distribution is precluded.

Nevertheless, I still think that going to MPL 2.0 for mainland tDOM should be considered by Rolf ...

Rolf Ade

unread,
Aug 8, 2018, 7:01:19 PM8/8/18
to

stefan <stefan....@wu.ac.at> writes:
> Nevertheless, I still think that going to MPL 2.0 for mainland tDOM
> should be considered by Rolf ...

I switched to MPL 2.0, on trunk. (Modifying 20+ files ...)

Are I'm now allowed to spend my time on sensible things?

But, truly, thanks for your contributions to this thread.

0 new messages