Simon Calderson wrote:
> As a simple example, CDRF shows how you can combine XHTML and SVG
> content in a single, compound document.
I think you're confusing WICD and CDRF?
> Iin particular, CDRF does not and cannot address the scope of ODF
> profiles: if the new TC is to define feature subsets of ODF that is
> useful in a CDRF context (e.g., you could create a CDRF-based profile
> which aimed at mobile devices which included an ODF profile), but the
> two operate at entirely different levels.
I don't think CDRF even tries to address the scope of ODF. The profiles
bit of CDRF merely states a few requirements of profiles. I wrote this
in another mail to the list as well:
[1] A subprofile only removes elements (or restricts it more) to a base
profile. It does not add to it.
[2] Given a profile X and it's sub-profiles Y and Z: An application
which supports profile X must also support the subprofiles Y and Z
(should not be hard to do, since there's nothing in those subprofiles
that's not in the Gamma profile. See [1])
I think that's the main reason Marbux is hammering so much on CDRF.
Personally, I like those points of CDRF. When adhered to, you can solve
quite a lot of the interoperability quagmire with profiles(*). I'm still
not convinced that we need all of CDRF, but the profile bit is
definitely useful.
(*) Example: Suppose there's ODF/I for interoperability and ODF/W, a
subset (subprofile) of ODF/I useful for web applications like Google
Apps. The profiles part of CDRF dictates that:
[1] Everying in ODF/W is also in ODF/I.
[2] When an application like OOo says it supports ODF/I, it means that
you can open an ODF/W document, edit it and it will save it in ODF/W
instead of ODF/I. That means that Google Apps can open it without issue
even though Google Apps only supports ODF/W and not all of ODF/I.
The sad part is that these good points that Marbux makes are entirely
lost in the enormously long posts -- burried under conspiracy theories,
legal flamebait and tin-foil hattery.
Sorry Marbux...
