2008/6/22 marbux <>:
>> Not quite Paul. 2.4.1
>> An attribute value that 'should be' a QNAME as per xml 1.0
>> A should be, not verifiable by a validation against the spec.
>
> Not sure I understand here. "Should" doesn't create a normative
> requirement. It's only a recommendation and a document can be
> conformant without the implementation/document abiding by the
> recommendation. So the way I understand it, one could test whether
> "should" has been done but the test result doesn't relate to
> conformance.
I'm interpreting a 'may' etc as test it, but you can't fail
anything without a 'shall' or 'must'. (Right or wrong I don't know).
It was the XML geekery I referred to.
The spec is littered with may.
W3C is shifting to recognising 'implementation dependent'
but becoming smart about how it's used.
Makes for portable specs with good implementations.
>
> Lapsing into an area where I have more expertise, there's a WTO
> Appellate Body ruling on the Agreement on Technical Barriers to Trade
> holding that a technical standard must: [i] fully specify all
> characteristics [ii] only in mandatory "must" and "must" terms [iii]
> of an identifiable product or group of products. That doesn't mean you
> can't have any options at all, the way I understand it, but you have
> to be really careful about how you word them and "should" really
> belongs only in in a best practices guide rather than in a standard.
+1
I'm moving towards a spec full of 'shall' language
with a supporting cast of
why we mandate it
this is how a user uses it
etc. I.e. fully normative/informative texts.
> Am I misunderstanding what you meant?
No, the XML use doesn't make for a
normative clause either;
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
