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] Informative clauses



"Dave Pawson" <dave.pawson@gmail.com> wrote on 06/23/2008 02:07:39 PM:

> 2008/6/23  <robert_weir@us.ibm.com>:
> >
> > "Dave Pawson" <dave.pawson@gmail.com> wrote on 06/23/2008 11:59:17 AM:
>
> >> >> 2.4.2 Base Settings
> >> >>
> >> >> The <config:config-item> element contains all base settings. The value
> >> >> of the setting is stored in the element.
> >> >>
> >> >> This is (barely) informative.
> >> >> No shall.
> >> >> No may
> >> >> Not marked as informative.
> >> >>
> >> >
> >> > It defines a schema fragment, so that creates a number of testable
> >> > provisions that will be subsumed into the schema validation portion of
> >> > the
> >> > conformance test.
> >> >
>
>
> >> Just count how many assumptions you've made to respond like that Rob.
> >>
> >> Reading the contents of the standard (and no more) that's basically
> >> not a testable clause.
> >
> > That clause gives a schema fragment.  Of course that is testable.  This is
> > very basic.  Please let me know that you see and agree with that assertion.
> >  Otherwise we cannot have a meaningful discussion on this topic.
>
>
> Then we can't have a meaningful discussion Rob.
>
> There is nothing in the spec that requires a vendor to be conformant
> to that fragment of the schema at that point.
> If, elsewhere, it requires conformance in the round, then fine.
> The spec is littered with ... text like that.
> Unclear, no normative requirements, plain bad spec writing IMHO.
>
> If you want to infer what is not present, don't be surprised when vendors
> claim compliance by ignoring your output because you have
> put a different interpretation on it to them.
>
> Your compliance tests will be worth nothing.
>

Let me connect the dots for you then, using ODF 1.1.

-----

Section 1.4 "Relax-NG Schema"

"The normative XML Schema for the OpenDocument format is embedded within this specification. It can be obtained from the specification document by concatenating all schema fragments contained in chapters 1 to 16. All schema fragments have a gray background color and line numbers."

-----

So the schema is declared to be normative.  By using Relax NG we have an ISO-approved formal notation for indicating structural and content requirements and options for XML.  Since 2.4.2 "Base Settings" is obviously a schema fragment (with gray background color and line numbers), this is included in the set of normative requirements defined by the schema.

Also, I think it is a false assumption the a vendor's main interest here is to claim conformance at the least cost and effort.  They can already do that if they want.  I think what ODF vendors want is to improve interoperability with ODF, to make document exchanges smoother and more predictable, and in doing so increase customer satisfaction and the overall value of their applications.  In other words, we want results, not just a token certificate that says we've passed a meaningless test.  Conformance testing is one part of this effort, but not the only part, and probably not the most interesting part of improving interoperability.

-Rob

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