Re: dom1.dtd not in CVS

> What language and/or implementation are you wanting to test?

  I am using an XML parser and DOM that I wrote myself that
is based on COM.  I have gotten it to completely pass the
previously released level 1 tests using JsUnit.  And I am now
working on the level 2 support.

  However, I want to get away from JsUnit and JUnit is not
acceptable either.  They both introduce dependencies from
the Java/DOM or JavaScript/DOM bindings that have
nothing to do with my COM bindings.

> The code generation templates are pretty numbingly complex XSLT.  Probably
> the best process is to:
>
> generate the Java tests
> manually transliterate a few of them to your target language, binding and
> xUnit test framework
> Transliterate the framework functions
> Get the few tests running
> Create a test-to-whatever.xsl from test-to-java.xsl to produce something
> like your transliterated tests
> Iterate

  I have noticed the "numbing complexity".  I want to avoid this all together.
I'm taking the approach to read the XML definitions of the tests and then
call the functions directly.  No intermediate source code generation.  The
COM standard provides all I need and I don't have to deal with language
specific binding issues either !!!!

  So I am far more concerned with changes to the DTD's used to validate
the test definitions than I am with changes or additions to tests in the suite.
In fact I have a task on my plate to programmatically generate tests to pass
though this framework.  So DTD stability is doubly important to me.

  Since the DTD's are generated, I guess the real question is how stable are
the inputs and scripts used to generate the DTD's ????

  Or maybe as a longer term solution, Is there any place I can get recently
generated copies of the test suite so I can avoid going though the whole build
process just to get a few files ????  It might not be a bad idea to include even

the generated components in CVS !!!!!

Joe Schafer
jschafer@iquest.net

Received on Thursday, 1 August 2002 06:50:07 UTC