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
