Summary of some "profiles" usage and ideas

[jose lorenzo <hozelda@yahoo.com>]

--- On Fri, 6/20/08, marbux <marbux@gmail.com> wrote:

> From: marbux <marbux@gmail.com>
> Subject: Re: [oiic-formation-discuss] The importance to users of documents looking the same
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Friday, June 20, 2008, 8:16 AM
> I just realized that I left a mental leap unexplained in my
> discussion
> of the branching opportunities using the CDRF framework.
> 
> What I describe assumes that the business process automated
> document
> assembly profile for a parallel profile would precede the
> development
> of a pixel-perfect profile for the same profile at every
> profile
> layer. Each pixel-perfect profile would superset the
> corresponding
> business process profile (the subset) with the two branches
> of
> profiles kept in synch.
> 
> Each business process profile would allow its extension to
> the
> corresponding picture perfect supersetting profile, but
> only so long
> as the implementations of the picture perfect profile were
> required to
> retain the ability to write to the business process
> profile, i.e., to
> process the business process profile as if it were the
> superset
> profile.

I wanted to highlight this example of super/sub profiles for anyone keeping score. The example is of a pair of profiles that work together. The superset adding picture perfect attributes (view) to what is otherwise more of a model.

Other references to profiles elsewhere (plus the occasional random thought) include:

-- defined by the application scope and capabilities. Eg: ODF/mobile; ODF/braille; ODF/advanced-calculator.

-- use cases/ end user needs (eg, the above business case were we to go into further detail). Note there are various categories of end users we have identified. Each of these might present new elements to the profiles picture. Eg: ODF/hospital-administration-at-my-co

-- based on degree of conformity to a base profile, for the same or similar feature set. Eg: ODF/core vs. ODF/core-strict vs. ODF/core-superstrict-level-12F-002.

-- defined within ODF vs. by third parties. Eg: ODF/core vs. Acme-cert/core. This might include defining the "profiles" themselves (whatever that means) as well as test suites and anything else related. Perhaps different parties contribute to different components of the whole. We might want to standardize a naming scheme for certs. There is also the issue of logos/trademarks for certs. A naming scheme based on results from testsuites....

-- profiles related through the addition vs. through the subtraction of (eg) features/elements. [might call for definition of "features"]. This would be an example of super/sub profiles but with emphasis on dual approaches for generating the profiles.

-- super/sub vs. overlapping partially vs. completely disjoint.

-- round-trip invariance. This is an issue when document are affected by apps of varying but partially overlapping feature sets.

[I still have to go through the "Profiles: suggested use-cases" thread http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00609.html and surely I am missing a lot more material.]