OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[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


----- 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.



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]