Profiles

[Shawn <sgrover@open2space.com>]

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

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?

Further to that, the idea that a "subset profile" or "sub profile" can 
only remove features from the base profile.  I believe this may help to 
make our jobs easier.  If we adopt this rule, then we only really need 
to define the high level profiles.  I picture a sub profile to be 
something like "Starting with the above profile, we'll restrict testing 
to table layout, including cell size, format, and merged cells. 
Formulas are out of scope for this sub profile"...

Hmm.. taking this high level profile idea a little further I see a 
natural hierarchy forming.  Something like:

ODF 1.1
- Document
   - Layout
- Spreadsheet
   - Layout
   - Calculations
- Presentations
   - Layout
   - Transisitions

And then sub-profiles being inserted where ever needed.

I'm not sure if the other points Sander raised are pertinent (not enough 
knowledge on my end to comment), but posted them here for discussion, 
just in case.

Some thoughts...

Shawn