Bug 006: Extensibility Policy

This is feedback on a Last Call Working Draft:

Evaluation and Report Language (EARL) 1.0 Schema
W3C Working Draft 10 May 2011
http://www.w3.org/TR/2011/WD-EARL10-Schema-20110510/

There is no clear EARL extensibility policy. Assuming that the
conformance section were moved to the right place (Bug 002), how would
a conformant EARL report be open to extension? The existing
conformance criteria do not say what is excluded, only what is
included. If I were to make up my own properties and classes, could I
use them in an EARL report? Under what constraints?

This is important, because extensibility can be used to hack around
what conformance criteria already exist. For example, the
specification allows for pass, uncertainty, or fail. But what if
somebody wanted to introduce a probablyPasses property? Then they'd
probably have to do this:

[ earl:result [ earl:outcome earl:passes, :probablyPasses ] ] .

Otherwise they wouldn't be conformant. Not very beautiful, is it? Or
they could make :probablyPasses an instance of earl:Pass, but that's
even worse. In fact, if they did what I wrote above, that would mean
that :probablyPasses is an instance of some kind of earl:OutcomeValue,
but it wouldn't be clear what. What shape, then, does this extension
have? And is it conforming? Not only would an extensibility policy
tell you that, but the conformance criteria too. So an extensibility
policy is really part of the conformance criteria.

In summary, there ought to be a clear extensibility policy,
intrinsically and probably intricately interconnected with the
conformance criteria. See also Bug 004 on the subject of investigating
how many language profiles are necessary, which will also affect the
shape of an extensibility policy.

-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Tuesday, 10 May 2011 22:39:54 UTC