Larry,
Le 18 juil. 2011 à 03:58, Larry Masinter a écrit :
It’s best to view RFC 2119 in the context of IETF rules for interoperability:
You might want to read this too.
http://lists.w3.org/Archives/Public/www-qa/2006Apr/0008
--
Karl Dubost - http://dev.opera.com/
Developer Relations Tools,
It's best to view RFC 2119 in the context of IETF rules for interoperability:
Progression along standards track depends on there being multiple independent
interoperable implementations of every feature.
While feature is not clearly defined, I believe that in a well-written
specification, any
On Mon, 11 Jul 2011 19:06:57 +0200, Karl Dubost ka...@opera.com wrote:
Le 11 juil. 2011 à 12:58, Aryeh Gregor a écrit :
The standards we're discussing are not coercive.
Just a minor semantics point. Web Standards are never coercive.
They might be used by legal framework aw as a reference
On Sun, Jul 10, 2011 at 5:04 PM, Charles McCathieNevile
cha...@opera.com wrote:
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
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
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
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
* 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
On Mon, Jul 4, 2011 at 5:47 AM, Rich Tibbett ri...@opera.com wrote:
We currently define tests in test suites for SHOULD requirements. A problem
occurs when those tests are used to gauge the overall compliance of an
implementation to the full test suite. An implementation could theoretically
be
RFC2119 'Key words for use in RFCs to Indicate Requirement Levels'
defines the keyword 'SHOULD' as:
This word, or the adjective RECOMMENDED, mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
On Mon, Jul 4, 2011 at 10:47 AM, Rich Tibbett ri...@opera.com wrote:
RFC2119 'Key words for use in RFCs to Indicate Requirement Levels' defines
the keyword 'SHOULD' as:
This word, or the adjective RECOMMENDED, mean that there
may exist valid reasons in particular circumstances to ignore a
On Jul 4, 2011, at 11:47 , Rich Tibbett wrote:
Wondering if there is any set W3C thinking on this or a way of including
SHOULD tests in test suites but clearly indicating that they are, basically,
optional and do not count towards the overall compliance score? I couldn't
find anything in
Rich,
Le 4 juil. 2011 à 05:47, Rich Tibbett a écrit :
conformance testing.
and later on
implementations to claim 100% compliance
These are entirely two different things. The MUST/SHOULD or any systems of
Conformance help articulate the way the technology is organized.
The claim of being
On Mon, 04 Jul 2011 11:47:22 +0200, Rich Tibbett ri...@opera.com wrote:
RFC2119 'Key words for use in RFCs to Indicate Requirement Levels'
defines the keyword 'SHOULD' as:
This word, or the adjective RECOMMENDED, mean that there
may exist valid reasons in particular circumstances to ignore
14 matches
Mail list logo
