This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
My experience is that untested hooks are bad; really bad. Please share this experience with your readers. This bit of SpecGL seems relevant, though not exactly the "untested hooks are bad" bumper-sticker I'd like to see: Make sure there is a need for the optional feature. 4.2 Good Practice A: in 4. Managing Variability of SpecGL The 1999 RDF spec had a couple hooks that were not well tested: [[ When an RDF processor encounters an XML element or attribute name that is declared to be from a namespace whose name begins with the string "http://www.w3.org/TR/REC-rdf-syntax" and the processor does not recognize the semantics of that name then the processor is required to skip (i.e., generate no tuples for) the entire XML element, including its content, whose name is unrecognized or that has an attribute whose name is unrecognized. ]] -- http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ The WG observed that implementations were all over the map, so we got rid of that one. http://www.w3.org/2000/03/rdf-tracking/#rdfms-para196 This one was sorta contradictory: [[ Other values of parseType are reserved for future specification by RDF. With RDF 1.0 other values must be treated as identical to 'Literal'. ]] I think the WG observed that implementations follow the latter sentence and standardized it, though I can't find the decision. There's a relevant test, http://www.w3.org/2000/10/rdf-tests/rdfcore/rdfms-literal-is-xml-structure/test005.rdf which seems to be associated with this issue... http://www.w3.org/2000/03/rdf-tracking/#rdfms-literal-is-xml-structure but I don't see a pointer in the other direction. I know we decided that using this as a hook for parseType="Quote" is not allowed: http://www.w3.org/2000/03/rdf-tracking/#rdfms-quoting I think SMIL has some system-foo hooks that are more well tested. There are plenty of other well-tested, well-used hooks in the web: HTTP mime types, XSLT extensions, CSS fallback rules (though those were, at one point, insufficiently tested) etc. The issue of untested hooks came up recently in a WG meeting I chaired; in editing the minutes, I was curious if SpecGL had an "untested hooks are bad" bumper sticker; almost... [[ SPARQL Protocol Spec We noted SPARQL Protocol for RDF W3C Working Draft 14 January 2005 ... Regarding the Abstract protocol, DanC noted that it comes with a testing obligation; if we're only going to test one concrete protocol, we should fold the essential material from the abstract protocol into it. He later clarified that it would be OK if a second concrete protocol (SOAP, SMTP, ...) were not normatively specified, but only specified in a Note or even only in the test materials; as long as the abstract protocol "hook" is tested, we've met our obligations. postscript: this bit of SpecGL seems relevant, though not exactly the "untested hooks are bad" bumper-sticker I'd like to see: Make sure there is a need for the optional feature. 4.2 Good Practice A: in 4. Managing Variability of SpecGL ]] -- http://www.w3.org/2001/sw/DataAccess/ftf4.html#item08
Seems to be a process/workflow issue. Under reviewing and testing, can mention putting in untested hooks. Add RDF story provided. ACTION: Add as technique in 5 GP B RESOLUTION: Agreed.
http://lists.w3.org/Archives/Public/www-qa-wg/2005Mar/0105.html Instead of 5 GP B where I don't think it fit very well, I made it a technique of GP18, as follows "Avoid "untested hook": if an extensibility mechanism is defined, make sure it is well tested during the implementation phase; experience has shown that untested extensibility just doesn't work"
setting version to LC in case of future use