[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?) http://lists.oasis-open.org/archives/oiic-formation-discuss/ > >> 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? regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk --------------------------------------------------------------------- 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]