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] Feedback to the ODF TC


--- On Sun, 6/22/08, Dave Pawson <dave.pawson@gmail.com> wrote:

> From: Dave Pawson <dave.pawson@gmail.com>
> Subject: [oiic-formation-discuss] Feedback to the ODF TC
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Sunday, June 22, 2008, 7:57 AM
> Classic example of vague untestable unclear statements.
> http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html
> search for para 2.4.1 (since the table of contents fails to
> link to
> the stated targets)
> 
> The config:name attribute identifies the name of the
> setting
> container. For top level <config:config-item-set>
> elements, that are
> elements that are direct children of the
> <office:settings> element,
> the name should be preceded by a namespace prefix that
> identifies the
> application the settings belong to.
> 
> 1. The config:name attribute identifies the name of the
> setting container.
> A statement, not a requirement
> 2. the name should be preceded by a namespace prefix that
> identifies
> the application the settings belong to.
> 
> No indication of which prefix aligns to which application
> (I might
> guess the intention is to use 'spreadsheet|drawing|text
> document', but
> it would be a guess.
> Asking for a namespace prefix to be resolved from an
> attribute value?
> No indication of what syntax to use for 'name' (in
> xml terms).
> 
> 
> This is why the TC needs to be able to feed these examples
> back to the
> main TC for cleanup.
> This should be a deliverable.
> 

We begin to build up a list of all anticipated issues with ODF (eg) 1.1. We categorize the problems if necessary. We optionally suggest solutions for each such item. We let the ODF TC know of the growing list. Formally, this TC (once the TC is created and the first draft of the list is finished) presents the list to the main TC at some point (this would be the first installment of a batch of related deliverables).

The ODF TC would have been keeping up and so can possibly resolve most issues quickly once presented with this official gripe list. They then let us know of their growing list of resolutions. We work off that unofficial list. Eventually, they return a full official reply, most of which should not be a surprise to us.

As necessary we repeat the process.

The point is to have everyone be aware of the build-up of problems/solutions before they are formally presented to the other group in order to decrease round-trip time and maybe even catch possible misunderstandings quickly. Also, we try to offer solutions along with the problem statement in order to further speed things up by making it easier on them and/or to suggest any preferences we may have.

Once such a list is started (unofficially Dave already started or added to it), we will be able to see what else we may do or if to tweak the process.

Another issue is how to achieve consensus over what goes on the official list. One approach is to have anyone present their items for the list and have each be considered individually (or in batches since multiple issues with potential fixes could be inter-related).

We can also simply keep growing lists and dialog and have no formal deliverable.

Separately, I think everyone that wants to work on ODF changes should do so and then approach the appropriate TC. OASIS would be foolish to reject really good work that was already done. But if they did, other parties outside OASIS might be interested. These parties might include antitrust authorities, other standards groups, and FOSS projects working on implementations.



      


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