Re: [oiic-formation-discuss] Profiles: suggested use-cases

[Sander Marechal <s.marechal@jejik.com>]

Dave Pawson wrote:
> My initial reaction is negative Sander. This is too close to
> a)Direct addition to the specification.
> b)Very little different to how some may want to treat extensions.
> You have gone beyond profiles into 'how to process' document variants.

I'm not sure I quite understand your objection. Could you explain a
little bit better? It is exactly my point that we describe how profiles
work in the real world, without nailing down any definition of
"profiles". Perhaps you can make some suggestions to improve the use-cases.

> Other definitions:
> 
> A profile which describes the use of ODF as an archive format for long
> term storage of documents.
> ...
> A profile which constrains ODF not to have any graphical content, for
> use with a tactile output device.

Personally I'd leave it up to the TC to figure out what profiles are
needed. Let them asses the ODF landscape, see what's going wrong with
interop and have them design a spec on "what's an ODF profile" and a
list of profiles it thinks will improve interop.

Your profile suggestions sound very useful, but it may not be the best
way to do profiles. Maybe the TC would prefer to create profiles based
on features instead of usage. E.g, instead of "ODF for archiving", "ODF
for the web" it would like to do something similar to XHTML2: "ODF
core", "ODF charts", "ODF styles", etcetera. I'd like to leave the
freedom to decide that to the TC.

Or perhaps they want to split ODF into four profiles: "ODF text", "ODF
spreadsheet", etcetera. In which case my use-cases go out the window,
because my use-cases are about conformance requirements for
subprofiles/superset-profiles. If the TC thinks it's better to create
profiles that are not subsets of other profiles, this doesn't apply (but
some other use-case may).

-- 
Sander Marechal