Re: Thoughts on 1.0 (better-thought out, better-formatted)

Hey there,

> 1. Replace the WebContent, Tool, and UserAgent subclasses
> of TestSubject with a single TestSubject class that can have
> some kind of type (earl:isa? something else?) property that is
> one of those three.

Impressive suggestion! As you noticed, there are various pros and cons to this approach, which BTW
can be made compatible with the current approach. Chaals already raised the main issue (which may or
may not be a problem), which is that this method leaves less room for extensibility and dual
typing - depending upon how it's arranged.

There are a few options and paths for giving the type of the test subject - for example, how many
earl:isa (or earl:subjectType, perhaps) properties is one allowed to have on a TestSubject? Should
the types be explicitly enumerated, or extensible?

The play off (similar to niq's Implementation vs. Stabilization conundrum) is between making things
simple and regular for lower-end tools, but powerful and flexible enough for later high-end tools.

> 2. Transform the essential element of an EARL document
> from an Assertor to an Assertion, and make the Assertion
> a four-part item that includes the Assertor.

Hmm... I think someone proposed this before, although I can't find a reference, so I might be
mistaken. It makes the XML RDF a bit verbose if you have an anonymous assertor asserting lots of
assertions (that could go into the twelve days of EARL), but I think that the choice is arbitrary
either way. In fact, one can just use [ daml:inverseOf earl:asserts ] in any case, so both methods
are acceptable from a coherent data POV.

Choices, choices...

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://purl.org/net/swn#> .
:Sean :homepage <http://purl.org/net/sbp/> .

Received on Friday, 15 March 2002 12:21:13 UTC