OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic-conform message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ebxml-iic-conform] RE: new Test Req doc


Mike and al:
 
Comments in line.
Also publicizing this thread on our conform sublist.
 
Regards,
 
jacques
-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Wednesday, July 03, 2002 12:29 PM
To: Jacques Durand; 'mkass@nist.gov'
Cc: 'matt@xmlglobal.com'; 'mmartin@certivo.net'; 'steve.yung@sun.com'; 'prakash.sinha@iona.com'
Subject: Re: new Test Req doc

At 11:50 AM 7/3/2002 -0700, Jacques Durand wrote:

Mike and al:

Since I have not heard any more comments on
what we discussed last conf call regarding the way
to organize Test Reqs and to define conformance levels/profiles,
I propose we carry on with it:

- we would consolidate all Test Reqs in a single (master, or base) file,
only keeping the organization of req items by spec modules (as currently done).

I'll be happy to do that. I'm currently finishing up level 3 requirements, and have
reiterated through level 2 requirements. Will post them tonight.


- each conformance profile/level would be defined in a separate file
that complies with Matt's schema.

This sounds very flexible and powerful.



- coverage attribute needs to be associated with the spec, not the
Test Reqs anymore. That means that ultimately we would end-up with
two docs: (1) the master Test Req file, (2)a list of spec sections#
with for each its degree of coverage by a subset of test req items#.
I'm trying to get Rik Drummond help on (2).


Just as an idea, I "marked up" a page of the MS spec, with the idea of
highlighting portions that are covered by a requirement ( green = full coverage ,
yellow = partial coverage ). 
The easiest way for someone to interpret how well the spec is covered is
to view the spec itself, with annotated areas pointing to the requirement id,
and colored according to coverage.  Just a thought.  I've attached an example
spec page.
It is not "pretty", but it would really let MS Tech Committee people know how
well their spec has been covered.
We use this method here at NIST to "mark up" a spec to determine our coverage of that
spec.
[Jacques Durand] sounds quite a good idea. But in addition to the color code, I'd represent
the degree of coverage somehow in a  "print" manner (don't discriminate the color-blind !
and also people may want a print version)
(e.g. <coverage:FULL>), and maybe add a label qualifying the test req number, e.g.
<testreq:r1.1.6> <coverage:FULL> The MIME Content-Type header for the Header Container MUST have the value "text/xml" in accordance with the [SOAP] specification. <r1.1.7>The Content-Type header MAY contain a "charset" attribute. 



- item numbering (ID field) needs be revised, as it should not reflect
levels anymore. We could use something like: specmodule# *1000 + item#, e.g.
6034 means the 34th test req item relating to spec module #6.
Or it could just be a totally arbitrary number.

I am OK with this.


- as in the future, conformance profiles may "override" keywords
such as RECOMMENDED, OPTIONAL, i'd suggest that we express these as
a separate attribute in the Test Req file, i.e. a separate field (currently
they are merged with the Assertion).

The keywords are already expressed as separate attributes. They only "appear"
to be joined to the Asssertion because of the XSL Transformation of the requirements
document.


Let me know if that's OK with you.

Regards,

jacques


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC