Re: [oiic-formation-discuss] Profiles

[Sander Marechal <sander.marechal@tribal-im.com>]

Shawn wrote:
> This was originally in the "MARBUX POINT OF ORDER, OBJECTION, AND 
> SUGGESTIONS No. 1" thread.  I believe that thread is mostly off topic, 
> but these points Sander brings up are a new topic (in my opinion)...
> 
> Sander Marechal wrote:
>  > * Referencing child objects is done by whatever way the parent format
>  > specifies natively.
>  > * An optional "profile" attribute can be used along side the content type
>  > * A way to access the child DOM from the parent DOM an vice-versa
>  > (including events)
>  > * Subset profiles can't ann features, only remove features from the base
>  > profile

(Note my typo: "ann features" should be "add features" of course)

I wasn't raising any points actually. I was just recapping the major 
points of the CDRF spec that Marbux posted as hailing the end to interop 
problems in four sentences. They're not my points. They're W3C's.

How this applies to ODF profiles and whether to reference this in the 
charter or just defer this to the TC is up for discussion.

Personally, I don't see the holy grail of interop in this. They're 
useful for sure, but strict adherence to this doesn't automagically 
bring us the interop heaven that Marbux described in his post.

> There has been some talk about defining a "profile".  If I were to say 
> "I want to test the visual rendering of an ODF 1.1 spreadsheet" - would 
> that work as a high level profile?  Or do we need to get right down 
> specifying sections of the standards definition?

Probably the latter. As I understand it, the full ODF spec (which ever 
version we pick to work off) becomes the base. Then we make profiles by 
removing functions.

For example: ODF/I (ODF for interop) may be a subset of the full ODF 
spec that removes the option for application-specific extensions. E.g, 
no MS-Office binary blob objects. No application-specific styling, etectera.

ODF/A (ODF for archiving) could remove all extensions. "Nothing but the 
standard".

ODF/M (mobile) could be a subset of ODF that removes some styles and 
features that won't work on small-screen mobile devices.

Etcetera, etcetera. Which profiles need to be defined and what's in them 
is work for the TC. Perhaps the charter could define a few of such 
profiles on the "deliverables" list (e.g, just ODF/I for example) with 
the rest of the profiles to be determined by the TC itself, depending on 
where most of the interop problems occur.

-- 
Sander Marechal