OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]