RE: [oiic-formation-discuss] Profiles. Attempting a definition.

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

I agree that if you are going to use the term "profile" to describe the different variants of handling the standards, the Wikipedia one is the best definition.  It actually, in my opinion, goes to the core of what ODF is about.  Metadata elements - what is in the file; policies - what we should and shouldn't do with the file; guidelines - what we suggest people do when it comes to dealing with the file (I know some people are having some pretty creative thoughts about that one).  All of these are important requirements, and should probably be defined in detail by the TC.  Hmm... isn't that basically what this list is about?  Figuring out what the TC should do and drafting a charter?  If so, can I suggest that we set several tasks for them?

1.  Establish a baseline.  Either we or the TC needs to set a baseline and say "from this point on, we will consider version X.y as our working standard."  I am inclined to think this should be the TC's responsibility.  I would respectfully submit that the TC keep open to comments.  Once a baseline has been established, however, discussion on the baseline should be brief, and should be more or less "Do we approve this as a baseline, yes or no?".  I suggest ten days maximum in order to keep things moving and still allow for some time to read the results of the baselining.

2.  Establish a profile standard.  For example, I submit that we follow something similar to the rules of normalization in a database, in which each successive level of normalization includes the previous level(s) plus a new rule or two.  Say we decide that the "basic profile" should be strictly compliant with version 1.0 of the ODF standard.  Then the 'Alpha' Profile includes the Basic Profile plus a nifty little suggestion from Microsoft, two from IBM and four more from Sun.  And the 'Beta' Profile includes all of the things in Alpha plus ten things from Apple, two more from IBM and four from Microsoft. 'Gamma' Profile would include all of 'Beta' plus... well, you get the idea.  That said, I would suggest that the most interoperable profile be considered the 'Basic' profile, and allow vendors to comply at different levels of interoperability with Alpha, Beta, Gamma, Delta, etc.  The higher you go, the less likely you are going to be completely interoperable, but if you stick to the lower levels, you should be more interoperable.  Maybe I have just suggested two separate approaches here as for a starting point.  I don't know, that may be for the TC to decide.

3.  Establish a feedback procedure.  A specification developed in a vacuum is a useless specification.  Web developers felt that they had no input in XHTML, hence their support of HTML5.  Many vendors and nations felt that they had no input in OOXML, hence their reluctance to see it made an ISO Standard.  (I also object to its being accepted as any standard, simply because it was developed by a single company and without outside input.  I would object to any such 'standard' developed by any single company, so Microsoft should not feel as though I am picking on them.  I didn't switch from my Commodore 128 to a PC until 1993 because I didn't like the 'IBM standard'.  I do still have my 128, if anyone's interested. :D )  Back to the point of a feedback procedure, we need to ensure that the TC not only receives feedback, but also responds to it within a timely manner.  To that end, I suggest ten days maximum for feedback to be given and ten further days for feedback to be acted upon.  There should be a final cutoff date for discussions, and it should be established prior to the discussions being initiated.  I would like to suggest a pattern of TC -> community -> TC -> Community -> TC.  Notice that I capitalized the word 'Community' the second time.  This was a typo, but on thinking of it, it actually makes sense.  The small 'c' community is the core group of developers, vendors, and others who will be directly impacted by decisions on the matter.  The 'big C' Community includes those who will end up using the results of the ODF standardization attempt, and any minor developer who may not be able to join OASIS even at the individual level (like myself), or the governments and people this format is to serve.

I welcome anyone's response on these matters.  Please feel free to add to them or to tell me how crazy my ideas are.

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: Shawn [mailto:sgrover@open2space.com]
Sent: Tuesday, June 17, 2008 2:54 PM
Cc: oiic-formation-discuss@lists.oasis-open.org
Subject: Re: [oiic-formation-discuss] Profiles. Attempting a definition.


Dave Pawson wrote:
> src->http://en.wikipedia.org/wiki/Application_profile
> an application profile is a set of metadata elements, policies, and
> guidelines defined for a particular application.
> 
> The elements may be from one or more element sets, thus allowing a
> given application to meet its functional requirements by using
> metadata from several element sets including locally defined sets.

Nice to see we are not the only ones who have difficulty coming up with 
a definitive description of a profile.  I think it is saying something 
when a "sample" of a profile is given to describe what a profile is. 
Sort of like using a word to describe itself.

I believe the Wikipedia definition is the most generic and probably the 
most appropriate for our needs here.  (of those listed)

> Profile, from list usage.
> 
> Use profile (is this an applications profile?)
> 1. A use case for ODF. E.g. Web based documents, e.g. Googledocs
> What parts of ODF are appropriate, essential, nice to have, less useful.
> E.g. Mobile profile. How ODF might be used on a mobile phone or PDA.
> E.g. Interchange profile. Some (reduced?) schema for document interchange
> and archiving. Readily validated.
> E.g. Accessible profile for non visual user. The application reading
> the document processes the same file list, but no visual styling is
> done. Audio and tactile output are produced.
> 
> Document Profile.
> Some variation (subset or superset?) of the ODF Schema for a purpose.
> Could be to 'enable', or satisfy a use case (application profile).
> Schema based, Adjustments to the schema are made to suite the use case.
> E.g. restrict the character set to (xyz) for use in Country xx-YY.
> E.g. rename all the elements using one of the DSDL mapping standards
> to make the elements usable in a non-Western country.
> 

I think the TC will need to deal with application, document, and 
standard specific profiles.  (standard specific, meaning to test part of 
the ODF standard that may or may not be part of an application or 
document profile).  Or would what I'm calling "standard specific" be a 
subset of the "document" type profiles?

But This is sort of what I was trying to get at earlier.  If we were to 
choose the Wikipedia definition of profile (or whichever the list 
decides is suitable) for inclusion in the charter, and offer some 
potential examples, that should leave lots of freedom to the TC to do 
what they need, but still have that starting point.

(btw, thanks Dave for doing the google search - you beat me to it...)

Shawn

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