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] Summary and Focus?

Dave, and all:

I commented on some of Dave's comments to Rob's points.  Some I agree with, others I thought to clarify or seek input.  Please consider what I wrote (included in rows of asterisks ['*']) and add input as necessary.  My suggestions for profiles may be off-base for some, but dead on for others.  And they are not detailed, just considerations I thought were necessary for what I see as different classifications of profiles.  Please note, I did not specify that these were application profiles, testing profiles, etc.  I think I generalized the considerations pretty well, but I could have missed one or twenty.  Feel free to tear me apart.

-----Original Message-----
From: Dave Pawson [mailto:dave.pawson@gmail.com]
Sent: Friday, June 20, 2008 2:04 AM
To: oiic-formation-discuss@lists.oasis-open.org
Subject: Re: [oiic-formation-discuss] Summary and Focus?

2008/6/19  <robert_weir@us.ibm.com>:

> Let me give this a try.

> I don't think the TC will be testing anything, in terms of downloading
> vendor software, executing tests of it, score and officially reporting the
> results.  We're not proposing the creation of a testing lab or the creation
> of a certifying lab.  But we are creating assets that could be used by third
> party testing labs, or by implementors directly, to evaluate their
> conformance to the ODF standard, and to evaluate interoperability scenarios.

My term was a test specification. Stating what tests need to be
carried out. A deliverable.
(Item 3 below)

> What I am hearing in terms of deliverables include the following:
> 1) Researching the state of ODF interoperability today and issuing a report,
> with recommendations.  Update this report periodically.

+1 (bit fluffy Rob? How to firm it up?) - Heavy overlap with 8 below.

Rob and Dave, 
Can I suggest rewording this to read like the following:
1) Report on current state of interoperability strengths, weaknesses and recommendations for future improvement.
Marbux may already have done some of this work, so if his points can be examined for validity - no offense, just trying to keep certain anti-corporate or anti-competitive language out of the standards - they can be included.  However, I respectfully suggest that the review for validity be done by someone or some group whose interests are in the best interest of the group, not a single company or group (other than OASIS).  In other words, a neutral party.

> 2) Researching the best practices in profiles, and issuing a "ODF Profiles
> Requirements" document

I'd like the TC to go further than this and define an appropriate
profiles list.

How does this sound for a partial list?

Base Interoperability Profile
-data specification language
-equation specification language
-element specification language
-document metadata specification
-internationalization specification (US English, Spanish, Portugese, etc.)

Visual Interoperability Profile
-all of the Base Interoperability Profile
-display specification language

Accessibility Interoperability Profile
-all of the Base Interoperability Profile
-tone specification language (audio)
-volume specification language (audio)
-other accessibility options

Printing Interoperability Profile (some of this may not be necessary)
-all of the Base Interoperability Profile
-printer option specifications (may be PostScript compliance, font specifications, etc.)

Some applications would not need to implement all of these profiles, others would need to implement them all, depending upon their function and audience.  For example, you really wouldn't expect a drawing program like OpenOffice.org's 'draw' to implement the Accessibility Interoperability Profile for the audio specifications, would you?  I am not trying to be insensitive here, but how many blind people use drawing tools?  Presentation tools maybe, but not drawing tools.  This is another reason why I pulled out things like Internationalization, metadata specifications, data specifications, and equation specifications into the 'Base Interoperability Profile'.  These are things that will apply to (almost) all applications, whether they have accessibility requirements or not.  It also means people can test base compliance separately from accessibility features.

> 3) Creating an "ODF Conformance Test Requirements" document that details the
> exact items required to test conformance of an ODF document and of an ODF
> application to the ODF standard.

+1. Clarification. "exact items required" means how each atomic item
in the standard
is to be tested.

See what I wrote above and use the 'bullets' beneath as a guide for test requirements.  Flesh them out if you want, I just generalized things a bit for brevity.

> 4) Creating an ODF Interoperability Test Requirements document that defines
> additional tests, including an Acid-like test and other interoperability
> tests.

-0 Until clarified. What does this mean? How is it different from 3?
We haven't come up with a definition of interop, how can we ask for it?
Suggest make it broader (as profiles).
Proposed "Define interoperability between similar ODF applications
(and documents?)
and propose suitable tests"

See what I wrote in response to #3.

> 5) Create the actual ODF instance documents needed to meet the requirements
> of the Interoperability Test Requirements above.

-1. Rationale. Up to the test implementers. Test data really. You won't know
what is needed until you write the tests. Devious ..... could ensure an
implementation is good for these snippets (and no more). Test data
needs to be very carefully considered when writing tests.

Dave, I agree completely.  The test criteria should be written, then a separate body should write a document that complies with the requirements, one that has a single error, and one that has multiple errors (to check the validity of the tests).  Once the tests have been validated, a document should be created with the application, then run through the tests.  IF the document passes the tests, the program produces valid output.  If it fails to open a valid file, it fails to pass the interoperability requirement.  Also, final testing should be accomplished by a neutral party, not the vendor.

> 6) Write profile of ODF to improve interoperability in specific areas.  I've
> heard ODF for archiving and ODF for web mentioned.

-1 We haven't clearly defined profiles. How can we require them,
how can Oasis test if we've got one back from the TC?
Bit like interop. Leave it up to the TC to define profiles and
produce an appropriate set of profiles of ODF, scoped to the latest
Oasis standard.

See number 3.

> 7) Write guidelines for ODF implementors on various topics, i.e., how to use
> the internationalization features of ODF.

-1. I think this workload would break the camels back. ODF implementation
is orthogonal to compliance and interop testing. If anything, this is a job
for the main TC. Weak testability is due to their work. Let them fix it.

This has nothing to do with compliance and interop. Hence my
proposal to reduce the TC name.

See again number 3.

> 8) Write a report on best practices in creating interoperable documents with
> ODF.

-1 as is. I want the TC to research interop, produce a definition scoped
to ODF apps and documents and then let the main TC know what they have
to do to improve it. Suggest this topic be changed into the feedback to
the main TC.

I agree.  Reporting on "best practices" just seems to be busy work for the TC.  Since there are a number of "best practices" documents out there on interoperability, those can be referenced by the TC.  I do agree that 'best practices' should be observed by developers, but I would put the onus of such research on the vendors, not on the TC.

> 9) Unspecified deliverables on improving interoperability with other markup
> languages, e.g., DITA, OOXML.

-10. Out of scope. Make a clear scope statement that this TC shall remain
within the scope of the latest Oasis standard. Interop between ODF apps
and via ODF docs.
Agreed.  It is important for developers to implement interoperability with other markup languages.  ODF should decide what markup language to use and be consistent.  IF that is to be XML, then all ODF documents should be in XML.  DITA documents should be in their format, OOXML in theirs.  If Microsoft wants OOXML to be interoperable with ODF, they can build that into OOXML (like they should have to begin with).  Standards should be 'silos'.  If it is HTML4.01 Transitional, it need not be compliant with RTF.  Two completely different standards.

> There may be some others (I need to go through the list traffic again), but
> does that list give you a better idea?

If I make time today I'll trawl the 350 emails to do that too.
Pity the archives aren't retrievable as a text file (are they?)

>> If we can determine this "focus", the discussion will be much more
>> concise and directed (I believe).

Would you do the same on scope please Rob. I take focus and
scope to be the same thing?


Dave Pawson

To unsubscribe, e-mail: oiic-formation-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: oiic-formation-discuss-help@lists.oasis-open.org

Garry L. Hurley Jr.
Application Developer 2
Office of Information Technology - Bureau of Application Development
PA Department of Labor & Industry
651 Boas Street, Harrisburg, PA 17121 
Phone: 717.506.9373 (UCMS) or 717.346.9799 (Harrisburg)  Fax: 717.506.0798  Mobile: 717.649.0597
www.dli.state.pa.us <http://www.dli.state.pa.us>

My comments do not reflect those of the Commonwealth of Pennsylvania, its various agencies and departments, or its citizens.  They are my own, and may or may not be shared by those in positions of authority over me.

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