RE: [oiic-formation-discuss] Summary and Focus?

["Hurley, Garry \(L&I - OIT\)" <ghurley@state.pa.us>]

Dave, et al.

I suggested some general profile types.  I think that all other types can be descendent from the ones I suggested.  One thing I wanted to say, and thanks to Sander for pointing it out to me in an off-list email, is that while I suggested such things as an "Accessibility Interoperability Profile" as containing all of the "Base Interoperability Profile" it should be specified that an application/document/test/whatever implementing the "Accessibility Interoperability Profile" should be able to produce a document that simply implements ONLY the "Base Interoperability Profile", which should be the default.  In other words, the default implementation should be the most interoperable profile applicable for the implementation.

As for references to various profiles solving all of the problems, you are right, they don't.  However, as stated above, I suggested profile types from which all profiles would descend.  That said, I tried to give generic descriptions of what would be included within those profile types.  Such information could then be used (once specified further) to generate the test cases, tests, and use cases for each type of profile.  (Items 4 and 5 below relate directly to testing).  For example: "Application foo implements the Printing Interoperability Profile.  We need to test it for compliance."  Okay, problem stated.  Solution:  Ensure that it is a proper implementation of the Base Interoperability Profile.  If not, it fails immediately.  If it is, test to see that the 'printer option specifications' sections are valid.  If so, it passes.  If not, it fails.

When it comes to Internationalization, that would be specified in the Base Interoperability Profile.  I basically saw no need to put Internationalization into a completely separate concern, as it would be required for basic interoperability.  (Where not specified, Internationalization standards generally assume one of two things - developer's choice or end-user's settings.  I would recommend strongly that the latter be mandated by the TC.)  If no internationalization settings are specified, the defaults are used.


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.

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


2008/6/20 Hurley, Garry (L&I - OIT) <ghurley@state.pa.us>:

> 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.

>> 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?

Put it on the 'wiki' page Garry. Useful.
I'm of the opinion that the TC should define a profile
then generate a useful list of profiles?

On that basis only I'm -1 on including them in the scope/deliverables.
If the TC  come up with more they won't be able to add them?

<snip/>


> *******
>> 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.
> *******


I don't understand how the references to various profiles will help
with the rest Garry?

Would you explain please.

regards DaveP


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

>
> *******
> See what I wrote in response to #3.
> *******
>

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

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

>
> *******
> See again number 3.
> *******
>
>
>


-- 
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