[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] PROPOSAL -- Name change for proposed TC
Sander, ----- Original Message ---- From: Sander Marechal <sander.marechal@tribal-im.com> Subject: Re: [oiic-formation-discuss] PROPOSAL -- Name change for proposed TC > 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? No. CDRF includes this as an example, see the first section. WICD is a CDRF Profile which specifies that, but that's beside the point. > 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: Actually, I think you're confused. CDRF "profiles" are **NOT** the same thing as we're discussing for ODF. A profile for CDRF purposes is simply a compound of a number of standards, in CDRF. So, XHTML + SVG is a "profile", let's call it Profile A. XHTML Basic + SVG is another profile, "Profile B", which is a sub-profile of profile A. CDRF specifies some basic rules by which you can combine standards: e.g., XHTML2 + SVG cannot be a sub-profile of Profile A. It says _nothing_ about where those standards come from: XHTML Basic is not a CDRF sub-profile of XHTML. Now, the confusion arises because XHTML Basic is a profile of XHTML. But that is a *different sort* of profile to what CDRF means. That is "profile" as in "a strict feature sub-set of the original specification", not "a group of different specifications". So, when you say: > (*) 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. .... you're actually conflating two separate issues. The profiles aspect of CDRF doesn't dictate anything to do with ODF profiles at all. It _does_ dicate how CDRF profiles which include ODF content can relate to each other, but doesn't help you get ODF/W. At absolute best, all you can say is that it would be good to design ODF profiles such that they can sensibly be part of the CDRF framework, but even that's a bit of a stretch because no normal ODF app is going to be interested in implementing the bits of CDRF which are outside the ODF specification (like the requirement to have a CDRF compatible DOM). In fact, the conformance criteria for WICD (a CDRF profile) are actually weaker than what we're talking about - they provide _less_ interop. A WICD Mobile-conformant user agent does not have to have any knowledge of WICD-full and CDRF doesn't say it should be able to process those documents in any way. If we setup a full profile of ODF, virtually nothing would be able to conform to it, possibly not even OOo. Thanks Simon. __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]