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

[robert_weir@us.ibm.com]

"Dave Pawson" <dave.pawson@gmail.com>
wrote on 06/22/2008 11:09:40 AM:

> 2008/6/22 marbux <marbux@gmail.com>:
> 
> > At least with elements attributes, just about every conformance
is
> > already tested by validation against the schema after all foreign
> > elements are removed.
> 
> 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.
> 

Whether something is testable or not does not depend
on whether it is a "shall" or a "should".  Both
are provisions of the standard, and both are normative.  "Shall"
denotes a requirement and "should" denotes a recommendation.
 Whether it is testable or not depends on whether the provision is
written precisely, accurately and clearly.  In particular, we could
define the test requirements such that violations of requirements and recommendations
are both reported, perhaps with different output classes, e.g., "error"
versus "warning" versus "informational".

> > That and the fact that there are no interop conformance requirements
> > are why I raised the issue of timing in what you want. I.e.,
do we
> > build tools for the existing spec or the repaired version. I'm
not
> > against what you want but I don't see the need for it before
the spec
> > is fixed unless the goal is application-level interop hacks rather
> > than a tool based on conformance requirements.
> 
> That's a catch 22 as I see it.
> 
> We can't fix the spec unless the TC is scoped
to do it.
> That's what the main TC is scoped to do (work the spec)
> hence until we have a list of :
> This is untestable please fix it,
> then go round the loop again
> Then we can test it.
> 
> That seems the most reasonable way to get what we both (all?) want.
> 

That makes sense to me.