Re: [oiic-formation-discuss] (1)(f) and (1)(g) -- audience and working language

["Sam Johnston" <samj@samj.net>]

On Wed, Jun 11, 2008 at 11:45 PM, <robert_weir@us.ibm.com> wrote:

"Sam Johnston" <samj@samj.net> wrote on 06/11/2008 10:39:23 AM:

>
> How about something like this? Are there others? We could offer an
> explanation of each as well.
>
> 1> Vendors
> 2> Integrators
> 3> Users
> 4> Purchasers
> 5> Authorities
>
> > I think I'd add:
> >
> > 6) Third-party certification labs
>
> An interesting point - they are likely to be more interested in
> quantitative outputs than the other groups.
>
> > Any others?  In particular, would conformity assessment documents,
> etc., be of use to government, to ICT policy makers, etc., or do
> they think of conformance and interoperability as merely a detail to
> be left to vendors to sort out?
>
> It seems likely there will be increasing involvement from these
> groups, particularly around 'proving' a standard rather than accepting
> it for face value. Making this task easier for them is arguably a
> noble cause.
>

OK.   If I cast it like this, does it still match your understanding?  Or have I missed something?

1. Implementors and Integrators of ODF applications and tools (I try to avoid the word 'vendor' since it isn't clear that includes open source projects)
2. Users of ODF applications and tools (In particular, I think we may want to create a report sometime along the lines of "Portable Document Authoring in ODF: Best Practices and Recommendations")
3. Procurers of ODF-related technology
4. Regulators or other authorities who specify the use of document format standards
5. Third-party testing and certification labs

On implementors and integrators:
I think there needs to be a distinction between implementors/vendors of ODF Editors/Suites (*Office et al) and developers/integrators of ODF tools, in that their needs are vastly different. The incumbent 'standards' are essentially a black box to all but the most courageous developers and I would like to see this change. Examples of applications I'm already thinking about as an ISV are metadata extraction, search filters, intelligent content management, etc.
I think it best to have a title and a brief explanation as well, as these are important points - we could afford to burn a few more cycles here to make sure the TC are considerate of their audience.

On portability:
This is something I have already been giving a good deal of thought to as one of the key drivers for ODF is metadata/search/archiving. I would like to see a 'profile' developed (as a deliverable) which would exclude certain 'difficult' functionality from documents, like macros for examples, links to other documents, macros, etc. and for want of a better name this profile could be called 'ODF/A' in line with its 'PDF/A' predecessor... or at least it could be the precursor to a separate TC on this topic. Again the 1.0 release could be fairly limited (eg excluding multimedia) but I think there should be some demand for such functionality, which could be somewhat aligned with PDF/A to avoid data loss (currently the most attractive archiving option is likely a lossy export to PDF/A - an extra unnecessary step IMO).

On presentation:
Touching on the points raised before about presentation, I think that in the dawning age of the semantic Web 3.0 (there, after resisting for so long I've finally said it), where data takes precedence over form, I believe our interop efforts should if anything sacrifice 'pixel perfect' rendering for data integrity if necessary. This is particularly true in light of the availability of a 'good enough' document format for presentation (PDF). There will always be a need for typesetting, but the world will be a better place if its information is 'organised, universally accessible and useful'. Another basic premise (and one of the primary things to go wrong with traditional documents) is that we're no longer confined to 8.5 x 11" (210 × 297mm over here in europe) sheets of paper, especially now people are starting to pay attention to the environment.

> > > Presumably 1g refers to a 'natural language', in which case US
> > > English seems the obvious choice (presumably this should be the same
> > > as the ODF TC).
> >
> > I'm not sure if the question is referring to the language of our
> formal output, or the language used in our conference calls and mailing list.
> >
> > I think our formal outputs should be in US English, but for the
> mailing list and phone calls, any form of English should be fine.
>
> Ok so what is in place for ODF and other similar groups? Locking it
> down to 'US English' in light of the formal outputs and tolerating a
> few s's and z's could be the best option, or simply specify 'English'?
>

My impression is most TC's just say "English".  The spell checker of the TC's editor will take care of the rest.

I've dropped this in the document as I don't anticipate much dissent.

Sam