RE: Editor's draft comments

 

Hi Shadi,

Comments to your comments ;o)

> Carlos Iglesias wrote:
> > * 2.2.2 Compound Assertor
> >[...]
> > <earl:compoundAssertor rdf:about="#assertor">
> >   <dc:title xml:lang="en">Bob using Cool Tool</dc:title>
> >   <dc:description xml:lang="en">Bob doing some 
> testing</dc:description>
> >   <earl:mainAssertor rdf:resource="#bob"/> </earl:compoundAssertor>
> > 
> > Should we add something else in the prose to prevent this 
> misuse of a Compound Assertor? 
> 
> How about "A Compound Assertor is a group of two or more 
> persons and/or software..." or something simple along those 
> lines. Anything else more elaborate could make the section 
> more complex and confusing, and there seems to be little 
> incentive for misusing the Compound Assertor in the first place.

Enough for me, maybe better with some emphasis on "two or more"

 
> > * 2.3 Test Subject
> > 
> > "dc:date: Date on which the subject was tested (or when it 
> was identified if more appropiate)"
> > [...]
> > As the creation date of the resource is the less relevant 
> for our use case, my proposal is using dc:date on Test 
> Subject for the date on which the subject was identified 
> (fetched), and use dc:date on Test Result for the date on 
> which the result was obtained (the test was run). Also note 
> that identification date and testing date may be the same in 
> several cases. 
> 
> Firstly, I think the date property in the Test Subject class 
> must be used to describe the test subject itself. In other 
> words, it should not be used to describe the testing date. If 
> we need a "testing date" then we should either put it 
> directly in the Test Result class (recommended) as part of 
> the description of the result, or in the Assertion class.

Agree, with Test Result as preference.


> As to the other two options, the date is dependent on the 
> nature of the test subject and I doubt we can easily find 
> consensus on its meaning. So instead of trying to define the 
> usage of the date property in the Test Subject class, I 
> propose we specify the usage of the (inherited) date property 
> in the Content class. This date should either be the creation 
> date if available (for example if the HTTP server provides 
> this header), or the identification date otherwise.

Also agree.

 
> > * 2.5 Test Mode
> > 
> > "mixed: Where a combination of persons and software tools 
> was used to carry out the test, but there is no detailed 
> information about the primary responsibility for determining 
> the outcome of the test. This includes when testing is 
> carried out by organizations or groups of assertors, and the 
> exact testing process is not disclosed."
> > 
> > It must be a compound assertor by definition, then we need 
> a mainAssertor (required for compound assertors) but in this 
> case it's impossible as the primary responsability is unknow.
> 
> No, it could be a foaf:Organisation too. Actually, I think 
> this was the original use case for the "mixed" value.

Then you will be defining foaf:Organization as a compound assertor in an implicit way, I think we should stay considering Organization as a kind of single assertor and then the problem remains, otherwise (if we allow Organization to be a compound assertor) this could bring us new issues with the definition of compound assertors.


> > * 2.6 Test Result
> > 
> > In order to benefit interoperability, shouldn't we add a 
> note to encourage people to use as many equivalent pointers 
> as possible?
> 
> Not sure if this belongs here, I think it is better placed in the 
> "Pointer Methods in RDF" document. At this stage, the term 
> "equivalent 
> pointers" may not be familiar to the reader.

Not sure exactly where (EARL or Pointers) but I think it should be somewhere.
Additionaly, I think that the meaning of "equivalent" is clear enough without any Pointer Methods knowledge as we use it in its "natural way".


> > --- Other editorial comments ---
> > 
> > * 2.4 Test Criterion
> > 
> > There are several inconsistences in the usage of "Test 
> Criterion" and "Testable" terms all around the section. The 
> easiest way to fix the problem may be to call the class 
> TestCriterion intead of Testable, this way we'll be also 
> consistent with the rest of the document (using the same name 
> for the class and the section of the document).
> 
> No, please don't open up this can of worms! ;)

Don't worry. I think this is easy and simple, in fact we are already using Test Criterion for everything except for the name of the class.


> > * 2.5 Test Mode
> > 
> > Is the only property that has its own section in the 
> document. Should this information be included in the 
> Assertion class section as we did with the Outcome?
> 
> Test Mode is actually a class, just a very simple one of 
> fixed values. 
> Outcome is also a class, which is why it also has a 
> sub-section (only at 
> a different node in the hierarchy).

Ok, forget all the mess I made about classes. What I mean is, shouldn't we also move TestMode to an Assertion sub-section (2.1.1) to be consistent?

 
> > * 3 Conformance
> > 
> > "...Each assertion contains information about a single test 
> that was carried out. EARL does not prescribe how to group 
> tests into a report since this is highly application and 
> end-user specific. For example, reports generated for Web 
> developers may contain more detailed results in order to 
> repair bugs while reports generated for project managers may 
> contain aggregated results with less detail on the specific issues..."
> > 
> > Shouldn't this information be in the Assertion section as a note?
> 
> I don't think so.

Why not?
I think this information it's relevant for the correct usage of the Assertion class as it has considerable influence in the support of aggregation of test results (Requirement F04 for EARL) and could go unnoticed in this section.


Regards,
 CI.

 
--------------------------------------

Carlos Iglesias

CTIC Foundation
Science and Technology Park of Gijón
33203 - Gijón, Asturias, Spain 

phone: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org

Received on Monday, 12 March 2007 18:04:50 UTC