- From: gsergiu via GitHub <sysbot+gh@w3.org>
- Date: Mon, 08 Aug 2016 07:43:39 +0000
- To: public-annotation@w3.org
@halindrome > @tantek you are not wrong. But let's not put too much importance on this "feature". It isn't a "feature" in the classic sense of the word. These are optional properties in a data model that might be present in content. There are no requirements that they be present, nor that they be interpreted if they are present. It's just advice. There are LOTS of such properties in this data model. The presence of absence of them in annotations generated by clients is something we will evaluate in the test cases. If they are present, we will test the values to ensure they conform to the requirements of the spec. But that doesn't really mean anything. At least, that's my interpretation. Thank you for the good hint ... We have a feature that is not a feature according to the text above. And you are write. ... we have a feature that is not documented trough a usecase, if you don't have a usecase defined, you cannot have a test case! No Usecase, No Testcase -> implies no feature!!! What speaks about movind these two "non-features" to the anex with the extensions, which is not normative? I do support @tantek 's point of view: > If untested or unimplemented or uninteroperable features (these properties) were explicitly at-risk, the group may drop them to help transition to PR. Otherwise untested/unimplemented/uninteroperable features (especially a novel approach as documented) must block a CR from transitioning to PR. -- GitHub Notification of comment by gsergiu Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/335#issuecomment-238163662 using your GitHub account
Received on Monday, 8 August 2016 07:43:48 UTC