- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Thu, 24 Apr 2003 22:24:10 +0300
- To: www-webont-wg@w3.org
Here is a quick review of http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/ Summary: I did not find this document helpful. It seems to address specs in mature fields rather than areas that are still in development. A lot of the priority 1 items either seem obvious or irrelevant (overly constraining). ====== It expands on the checklist found in: http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/qaframe-spec-checklist#checklist-table To exemplify why this document is not helpful I will go through the priority 1 items with ref to WebOnt and RDFCore documents 1.1 Include the scope of the specification. [Priority 1] Not every rec in the multi-document recommendations does this. It probably doesn't matter, as long as together the scope is clear. 2.1 Identify all classes of product. [Priority 1] Both RDF and OWL documents and WGs have avoided doing this, on principle. Neither technology is sufficiently mature to make this a useful task. 2.2 For each class of product, define the conformance requirements. [Priority 1] Ditto. RDF has eschewed conformance statements. For OWL we decided to define conformance statements for documents and for two classes of idealised processors which I do not believe will exist in practice. [For example, we defined an "OWL Syntax Checker" - I have written one, but it, by itself, is not hugely useful - more useful functional can be built on top of it, by being encouraged to conform however, my useful functionality built on top will interoperate with X's useful functionality built on top of X's conformant (but equally useless) OWL Syntax Checker] 3.2 If special conformance terms are used, include a definition in the specification. [Priority 1] Again "in the specification" needs to be aware of multiple document publication. 3.3 Justify any usage of a dimension of variability [Priority 1] The OWL documents as a whole do this - but for instance the OWL Test document, which contains the conformance statements, does not. 4.1 Indicate whether or not the use of profiles is mandatory for conformance. [Priority 1] Hmmmm "profiles???" This seems to correspond to the OWL Lite, OWL DL, OWL Full sub-languages ... Our conformance statements in http://www.w3.org/TR/owl-test/#conformance are clear in their relationship with these sublanguages without "Indicat[ing] whether or not the use of profiles is mandatory for conformance." So minimally these seems poorly phrased. Basically I think OWL does alright here, yet does not meet this requirement. So the requirement seems faulty. 5.1 If modules are chosen, indicate any mandatory conditions or constraints on their usage. [Priority 1] I don't think we have modules ... 7.1 Identify each deprecated feature. [Priority 1] Not done in OWL (first version no legacy). Not sure about in RDF, unqualified attributes comes to mind. 7.2 For each class of product, specify the degree of support required for each deprecated feature and the conformance consequences of the deprecation. [Priority 1] 7.4 Include an explanation for the deprecation. [Priority 3] Including lots of ratrionales can make the text too long and unwieldy. Better to have public WG e-mail lists - then the rationale is world visible. Keep the documents clean - never apologize, never explain. 8.1 State the circumstances for when discretionary items are allowed [Priority 1] There is a small amount of this done in RDF semantics (discussion of semantic extensions) - however both OWL and RDF are foundational and allow things to be built on top - any of this building on top is discretionary - there seems to be a general rule that such building on top should be monotonic ... Exactly which datatypes are required seems unclear ... 8.2 For implementation dependencies, address the allowable differences between implementations [Priority 1] [[[ Conformance requirements: the specification MUST describe any permitted variations or constraints for how the implementation dependency is realized by implementations. Examples of permitted variations or constraints to be addressed include: implementation dependent ranges, data, minimum or maximum values, environmental resources (e.g., memory or disk limitations), environmental values (i.e., language and local settings). ]]] we don't do that - yes these things impact implementations, and so? - we can't say anything useful, and so we don't waste our breadth. 9.1 Indicate if the specification is extensible. [Priority 1] 9.2 If extensions are allowed, define their scope and constraints. [Priority 1] 9.3 Prevent extensions from contradicting the specification. [Priority 1] 10.1 Include a conformance section. [Priority 1] Again, in a multidocument publication this may only be in one document. I don't have much problem with RDF not having this. 11.1 Identify and define all conformance designations. [Priority 1] OWL did this, RDF did not (well unless you count the empty set, but then people, including myself claim conformance to RDF) 11.4 Impose no restrictions about who can make a claim or where claims can be published. [Priority 1] OK we didn't ... 13.1 Use conformance key words. [Priority 1] I find connolly's "MUST is for agents" discussion compelling. Thus the conformance keywords should not be used except for agents. 13.2 Distinguish normative and informative text. [Priority 1] Both groups have been doing this. 13.3 Use consistent terminology. [Priority 1] Easier said than done. Both groups try to do this. My browser when faced with http://www.w3.org/QA/WG/2003/02/qaframe-spec-extech#Ck-no-claim-restrictions gets a redirect to http://www.w3.org/QA/WG/2003/02/qaframe-spec-extech-20030203 and loses the frag ID, I don't know if this is a browser problem or a document problem. It seems odd to have a recommendation with lots of points when the CR exit criteria did not require any implementation of all of them. I think WG will pick and choose out of this list. Jeremy
Received on Thursday, 24 April 2003 16:24:01 UTC