- From: Sarven Capadisli <info@csarven.ca>
- Date: Thu, 4 Jan 2024 14:28:58 +0100
- To: public-webid@w3.org
On 2024-01-04 00:50, Nathan Rixham wrote: > I would like to propose that any WebID specification authored by this group > must provide a testable way to determine that a WebID denotes an Agent. It goes without saying that testing is important and encouraged in W3C, and I support it for this CG - as I've done in Solid CG: https://solidproject.org/ED/qa - where possible. I'd add implementation experience, i.e., implementation reports to the proposed constraints, or at the very least commitments to implement. We can operate on honour as opposed to calling the implementation report police if someone doesn't follow through. Let me share a snippet from a comment ( https://github.com/w3c/WebID/issues/17#issuecomment-1877081434 ) that goes a bit further on testability: >"Testing" does not strictly entail automated scripting and verification. **In fact**, [W3C EARL](Evaluation and Report Language (EARL) 1.0 Schema), which is one of the key outputs of the [W3C QA Activity](https://www.w3.org/QA/Activity), provides a set of [Test Modes](https://www.w3.org/TR/EARL10-Schema/#TestMode), including: "automatic", "manual", "semiAuto", "undisclosed", "unknownMode". >So, conformance in a specification can be written in different ways towards what would qualify as a product to be interoperable. In practise, not every notion or requirement is necessarily tested or applicable or only testable with a single test case. That said, of course being testable strengthens the legitimacy of implementation's conformance through reports. But even then EARL for example acknowledges possible [Outcomes Value](https://www.w3.org/TR/EARL10-Schema/#OutcomeValue) such as "cantTell", "inapplicable", "untested". >Certain notions or intentions of a specification may not be practical to test. Take for example the notion of [URI Ownership](https://www.w3.org/TR/webarch/#uri-ownership) as per Web Architecture. If the owner of a URI says that it is allocated to represent today's weather, or an agent's profile (document) - and that can be stated in many ways - it does not entail that there must be specific wording/statement in a given representation with a specific testing. If there were to be the case, it would be generally infeasible or impractical to test. That's just an example. When I say https://csarven.ca/#i is my WebID, it is so, first and foremost, because I said so (even just with this sentence). As the URI owner ( one of the intended audience: https://github.com/w3c/WebID/pull/29 ), I also have the responsibility to manage its representations. To quote a AWWW principle: "Reference does not imply dereference". So, when the WebID spec defines WebID (the identifier) using an existing URI scheme (HTTP), there are limits to what can be tested. (It certainly does not entail coming up with several specs.) >I've shared quite a bit of considerations in https://github.com/w3c/WebID/issues/21#issuecomment-1875278872 essentially about expressing conformance requirements and interoperable product classes, categories of the specification, and weighing actual complexity / fragmentation of alternatives. -Sarven https://csarven.ca/#i
Received on Thursday, 4 January 2024 13:29:06 UTC