W3C home > Mailing lists > Public > www-dom-ts@w3.org > June 2001

Re: Early XSLT's

From: Mary Brady <mbrady@nist.gov>
Date: Mon, 11 Jun 2001 17:09:59 -0400
Message-ID: <002101c0f2ba$e06e0780$0100a8c0@happy>
To: <www-dom-ts@w3.org>

----- Original Message -----
From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
To: <www-dom-ts@w3.org>
Sent: Monday, June 11, 2001 4:30 PM
Subject: RE: Early XSLT's

> > [mb] I would prefer not to see additional efforts, rather for
> > those who are
> > interested in DOM testing to contribute to the
> > W3C DOM WG effort.  I'm sure we can work out a way that a generic
> > transformation can be made available as a
> > starting point for a particular language -- I would think that placing
> > additional licenses and personal copyrights on
> > the transformations will inhibit the overall effort, not
> > contribute to it.
> I've been working under an assumption of good faith and have been making
stuff available with no explicit copyright or terms of use.  However, I'm
starting to get a little uncomfortable with my
> personal exposure by doing this.  By asserting a copyright and GPL, I at
least cover myself by providing a standard liability disclaimer.  I'm still
free to donate the code to the W3C, when and if
> desired, to be released under an appropriate license.

[mb] I understand your concerns, as we have done the same.  By doing so, you
are also free to choose not to donate the
work as well.  Given that this work has come out of discussions from this
group, I'm surprised to see any copyrights or
licenses other than what was known up-front as part of participating in this
process.    Maybe I'm overlooking something
obvious -- it's not my area of expertise, and any work that NIST produces
must be made available in the public domain.

> Whether code generation templates are part of the test suite or part of a
specific harness implementation is questionable.
> > > I should be able to make the code JUnit independent,
> > however test classes
> > will require that the base class, DOMTestCase, provide
> > JUnit-like functions
> > such as assertTrue, assertFalse, etc in addition
> > > to implementing utility functions like load,
> > implementation, wait, etc.
> > >
> >
> > [mb] I would expect that these functions would be implemented
> > as part of the
> > transformation, given that they will have to be
> > done for each language.  There can be a set of helper
> > functions that get
> > created for each language, and are then called -- which
> > makes for good coding practice, but requires that these functions be
> > available along with the tests, or the logic can be inlined
> > in the transformation -- which makes for stand-alone tests,
> > and fits in with
> > contributions coming from many places.
> I wouldn't expect them as part of at least this transform since it is
concerned with building individal java source files from individual test
files.  The implementation of assertTrue, assertFalse,
> load, etc is not specific to any one test and is best implemented in a
hand coded common ancestor class.  The implementation of these functions
depends on the underlying testing framework.  If done
> appropriately, then running the generated tests on an arbitrary test
framework might only require the hand coding of the appropriate base class
and not require any changes to the generated tests.

I think I see what you are thinking -- when we develop our own set of tests,
we take similar approaches.  I've looked over other folks code,
and have seen very different thinking, which makes me wonder if it is better
to have the transform produce the code, and thereby remove any
dependencies on a harness.   Harnesses typically provide us with the ability
to reuse code, provide an easy way to run all of the tests, and
provide regular reporting mechanisms.  Maybe we should reach agreement on
what we want to support in the overall framework and what
we should support inside the tests.

Received on Monday, 11 June 2001 17:05:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:03 UTC