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] My perspective. display perferct?

2008/7/1  <robert_weir@us.ibm.com>:
>> I'm sorry. In which case I'd like the TC to be rechartered to work 'the
>> next'
>> version of ODF, as and when it is an Oasis standard and not before.
> Could you suggest some reasons why the proposed TC would not want to have a
> charter that takes into account the ODF 1.2 work which is already nearing
> completion?  Is there a particular advantage to ignoring this work?

Simply because it isn't an Oasis standard at this time of writing.
If, when the TC is constituted, 1.2 is the current Oasis standard,
then quote that.
Until then, 1.2 and any other 'non existant' Oasis standards are
properly undefined
 and hence created an undefined workload for the TC. My previous point.

> I never said that you mentioned profiles.  I said that your proposed
> restriction on testing application rendering (pixel perfection) impinged on
> a proposal made by another member of this discussion list who asked for the
> proposed TC to consider an ODF/Web profile.  Remember scope cuts across all
> deliverables.

In which case I would ask that the 'pixel perfect rendering of web profiles'
is also out of spec. No different.

If you start quoting actual profiles I'd ask you to go back and read the list.
The TC should define profiles. Not us

> It is common language in OASIS TC charters to say something like "The TC
> will develop and maintain XXX", where "maintain" implies future updates,
> revisions, etc.

Is that another unwritten Oasis rule that you're hiding Rob?
Custom and practice or some such?

  I'd like to hear your argument for why the proposed OIIC TC
> should be an exception to that practice.

Until you mentioned it I didn't know of that practice.

 Remember, scope does not oblige us
> to work on "all versions of ODF ad infinitum  into the future", but it does
> permit the TC to choose to work on the interoperability of any ODF release
> they decide to.  What is your objection to letting the people who will do
> the work, decide which versions of ODF are most relevant to that work?

It's not a clear work package without a defined version of ODF on which to work.

> In general I'd advise discussion participants to focus on things that they
> want added to the charter which they personally would participate in the
> development of.

Another c&p?

You keep adding to the workload and you'll have no one bothering Rob.

Dave Pawson

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