Re: CfC: publish Last Call Working Draft of Web IDL; deadline July 7
On Sat, Jul 9, 2011 at 7:23 AM, Arthur Barstow art.bars...@nokia.com wrote: Although there are ongoing discussions regarding exceptions, there were no objections to this CfC. As such, I will request publication of a LC specification to encourage broader review and comments. Sorry, I'm in the midst of sending comments on WebIDL. I should be done by Tuesday...
Re: CfC: publish Last Call Working Draft of Web IDL; deadline July 7
On Sun, 10 Jul 2011 20:01:17 +0200, timeless timel...@gmail.com wrote: On Sat, Jul 9, 2011 at 7:23 AM, Arthur Barstow art.bars...@nokia.com wrote: Although there are ongoing discussions regarding exceptions, there were no objections to this CfC. As such, I will request publication of a LC specification to encourage broader review and comments. Sorry, I'm in the midst of sending comments on WebIDL. I should be done by Tuesday... Hi Josh, do you think these comments should hold up the request for last call, or are you happy for that to go ahead? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Test suites and RFC2119
On Wed, 06 Jul 2011 00:32:42 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: Generally, if something is important enough for interop that we want to test it, we don't want to make it a should requirement. It should be a must. What examples do you have of should requirements that you want to test? Privacy and security restrictions leap to mind. There are things that really are should requirements because there are valid use cases for not applying them, and no reason to break those cases by making the requirement a must. In the normal case where they are applied you want to be able to test. But the difference between should and must is already two sets of conformance profiles (or whatever you want to call it), where one applies always and the other applies unless there's a reason not to do the thing that is assumed to be normal. cheers -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Test suites and RFC2119
On Sun, Jul 10, 2011 at 3:59 PM, Charles McCathieNevile cha...@opera.com wrote: Privacy and security restrictions leap to mind. There are things that really are should requirements because there are valid use cases for not applying them, and no reason to break those cases by making the requirement a must. In the normal case where they are applied you want to be able to test. Were you thinking of specific examples? I can't think of any offhand. But the difference between should and must is already two sets of conformance profiles (or whatever you want to call it), where one applies always and the other applies unless there's a reason not to do the thing that is assumed to be normal. The difference is that if you have must requirements that are specific to a single conformance class, you can write a test suite and expect every implementation in that class to pass it. For should requirements, you're saying it's okay to violate it, so test suites don't make a lot of sense.
Re: Test suites and RFC2119
On Sun, 10 Jul 2011 22:34:59 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: On Sun, Jul 10, 2011 at 3:59 PM, Charles McCathieNevile cha...@opera.com wrote: Privacy and security restrictions leap to mind. There are things that really are should requirements because there are valid use cases for not applying them, and no reason to break those cases by making the requirement a must. In the normal case where they are applied you want to be able to test. Were you thinking of specific examples? I can't think of any offhand. The most recent example is the Contacts API from the DAP group, but this is a pretty common pattern. Geolocation went through a long discussion on the topic. But the difference between should and must is already two sets of conformance profiles (or whatever you want to call it), where one applies always and the other applies unless there's a reason not to do the thing that is assumed to be normal. The difference is that if you have must requirements that are specific to a single conformance class, you can write a test suite and expect every implementation in that class to pass it. Yep. For should requirements, you're saying it's okay to violate it, so test suites don't make a lot of sense. Not quite. I'm saying that there are cases where violoating the requirement is reasonable, so test results shouldn't determine simple conformance. On the other hand, where these are things that in *most* cases we want interoperability, it makes sense to have test suites so people who don't violate the requirement can check that what they are doing is consistent with what others do. Essentially the question shouldn't revolve around the tests themselves - tests can be useful even when they're not determining pure conformance. What matters is how you use the results. Performance tests are another class of tests that can be very useful, allowing people to understand what sort of things work well and what sort of things might cause real-world problems, without normally giving any information about actual conformance. cheers -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Test suites and RFC2119
* Aryeh Gregor wrote: The difference is that if you have must requirements that are specific to a single conformance class, you can write a test suite and expect every implementation in that class to pass it. For should requirements, you're saying it's okay to violate it, so test suites don't make a lot of sense. And if I make an implementation that does not fit in any of the classes I can just argue that the specification did not anticipate the class my implementation falls in. You would have to explain how arguing about a missing conformance class is better than arguing about whether should level requirements have been met. With your model you would have more clarity, but you would also be more wrong, and require more effort to make things right, in addition to inhibiting innovation. I think that's a very difficult argument to make and we have should because of that. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
