Re: [oiic-formation-discuss] Deliverable: odf-diff?

["Dave Pawson" <dave.pawson@gmail.com>]

2008/6/22 marbux <marbux@gmail.com>:

>> 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