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] Level of detail needed in a TC Charter

2008/6/13  <robert_weir@us.ibm.com>:
> "Dave Pawson" <dave.pawson@gmail.com> wrote on 06/13/2008 11:07:44 AM:
>> 2008/6/13  <robert_weir@us.ibm.com>:
>> > That is how I read it as well.  (1)(f) asks us to list "the anticipated
>> > audience or users of the work".  So this is those who will directly
>> > consume,
>> > use, read, etc., the deliverables of the TC, not the larger list of
>> > those
>> > parties who may indirectly benefit.  Obviously in our work, we can and
>> > should be mindful of these other parties, but that doesn't need tobe in
>> > the
>> > response of (1)(f).
>> >
>> > -Rob
>> Perhaps you'd like to phrase something for this groups output Rob.
>> If you insist on that interpretation.
>> "Those who will consume, use, read etc" isn't a very tangible set of
>> users.
> I'm sorry Dave, I'm afraid I can't do that.  The definition given ("the
> anticipated audience or users of the work") is what OASIS gives us.  We have
> no ability to change that.  I'm suggesting an interpretation that seems
> obvious enough to me.

Which paints a picture of a real nice dictatorship.

Request please Rob.

Go back to the people who wrote this fluff and ask them for a

While there it may be politic to see if Michael is right about this quote

"What I'm missing a little bit is to provide guidance for implementors.
Simply speaking, the best way to achieve interoperability between ODF
applications is that these application implement as many of ODF as
possible and reasonable for the specific application, and with as little
bugs as possible. Tests are helpful to measure the quality of an
implementation, but they don't help implementors with the implementation

So far we have suggestion for tests, but we do not have suggestion how
we can help implementors in their implementation work.

It would probably be too simple to just put an "ODF Implementors
Guidelines" on the list of deliverables, since we don't know if
implementors have issues with implementing ODF, and if so where. So,
preparing guidelines, which is a huge effort, without knowing where the
issues are has the risk we are doing something no one needs.

Is this TC expected to provide guidelines for implementers of ODF
or guidelines for those implementing tests?

It is really silly to expect us and the following TC to work in the dark
without recourse to the source of our direction. Pure C19.


Dave Pawson

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