Re: New list of discretionary items

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 00/08/09 14:08 -0400, David_Marston@lotus.com wrote:
>Tony, thanks for composing the update. You noted:
> >The additional items don't always fit well with the idea of recasted
> >the text of the Recommendations as a question that can be answered
> >by 'yes' or 'no'.
>
>I think that yes/no is too much to hope for. It would be very nice if
>we could get the answers down to a range of keywords. Conceptually,
>this would be like "What languages do you support for sorting?".

However, can we not scope our *first* version of the test suite to be as 
simple as possible, perhaps even deferring cultural sort schemes?

>Now
>the point about passing parameters to the stylesheet probably
>devolves to a set of keywords that represent the syntaxes used by
>all the vendors. Presented for your consideration: the question is
>"How does your processor accept external parameter settings?" and
>the choices begin with these keywords: CANNOT, API_ONLY,
>NAME_EQUAL_VALUE (foo=bar), DASH_P_SPACED (-p foo bar),
>DASH_PARAM_SPACED (-param foo bar), and more as we encounter more
>syntaxes.

I feel this is out of scope.  A simple binary "supports external parameter 
assignment" is enough information in the configuration instance to 
configure test files and test results that test that parameters can be 
assigned ... *how* a parameter gets assigned will be addressed by the 
harness makers.  While I agree it would be nice to have one source for all 
configuration information, I would not want to constrain harness makers 
with the values we try to predict in our configuration instance ... I'd 
rather keep the configuration instance for the tests separate from the 
configuration information for the harness.

> >The XPointers that are being used to identify the elements in the
> >Recommendations containing the descriptions of the discretionary
> >behaviour don't provide enough granularity to differentiate the two
> >areas in the one paragraph.
>
>You ain't seen nothin' yet when it comes to granularity! I think we
>should plan on our own added-in tagging scheme to get down into
>sentence fragments.

I agree.

>Some test cases have to test the interaction of
>multiple passages in the specs (so-called "molecular tests") and
>thus would need to cite more than one fragment.

Could these perhaps be deferred to a 1.1 of the suite?  My objective is to 
scope our work to get something out that is useful, if not comprehensive, 
to both mark success and begin getting feedback.  The earlier the 
better.  Once a version 1.0 is out with "atomic tests" perhaps then we can 
look at expanding it to "molecular tests".

>Since the tests
>need to cover so much of the text of the W3C recommendations, the
>additional work to mark discretionary and vague areas will be
>minor.

I'm not sure what you mean here.

I can take on the action item of seeding an XML version of the 
Recommendation with ID anchors so they can be referenced by IDREFs (much 
like I did for the summary of the XML 1.0 Recommendation in the XML 
Conformance Suite, except for the entire document and not just section 
heads).  David, have you yet documented your requirements for granularity 
for the citations already made by the Lotus tests?

............. Ken

--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/m/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Book: Practical Transformation Using XSLT and XPath ISBN1-894049-05-5
Next public instructor-led training:        2000-09-19/20,2000-10-03,
.2000-10-04,2000-10-05,2000-10-19,2000-11-12,2000-12-03/04,2001-01-27