> >3) Possibly for those cases that can't be handled by (2), use a file
> >naming convention, like axes01-xalanc.xml.
>BTW, this should have been axes01-xalanc.out. Same as Shane's proposal.
The problem is that the naming scheme will become multi-dimensional. We
want to accommodate not just multiple processors, but various options
about encoding and serializing. A single processor may be able to produce
numbered or named entities, possibly with a different policy for
different numerical ranges, and we might consider this a product feature.
Rather than use an XML-parser-based comparitor and disguise the
differences, we would want to check the file to see that we really got
the in one case and the   in the other case. Separate policies
would apply to the notorious URL encoding.
To answer Ilene's point: you could use a plainer name for the results that
represent the defaults. I don't know how you can say that one of XalanC,
XalanJ-interpretive, or XalanJ-compiled is the "default", however. If you
get all three to use the same naming scheme in generate-id(), and get all
three to have the same encoding/whitespace/entity policies as defaults,
then that question might be moot. I think all three already have the same
policies on the discretionary choices in the specs.
Once again, I think the magnitude of the problem is somewhere between
50-100 tests, at least until we get into a broader range of natural
languages.
.................David Marston
