- From: Sean B. Palmer <sean@miscoranda.com>
- Date: Tue, 10 May 2011 23:39:26 +0100
- To: public-earl10-comments@w3.org
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