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 proposedTC


Simon Calderson wrote:
> 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.

/me reading the CDRF for the fourth time this week

Ah, I see now...

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

Okay, I think I understand. In that case, is there some standard that 
does describe how to handle these subset profiles? I still think that 
the example I have is valid, even if it does not have anything to do 
with CDRF. Updated example:

>> Example: Suppose there's  ODF/I for interoperability and ODF/W,
>> a subset (subprofile) of ODF/I useful for web applications like
>> Google Apps. Requirements:
>> 
>> [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.

That's the same example but with the references to CDRF removed.

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

Good point. Perhaps a point [3] should be added to my example that 
explains how an ODF/W application should treat ODF/I document. Or how we 
can insure that an ODF/I document works correctly when opened in an app 
that only implements ODF/W.

Then hand that example off to all the smart folk on this list to convert 
the example it to "standards jargon" useful to put in the charter? Or 
add as a strong recommendation to the charter?

I still like the idea, even if it's not CDRF.

-- 
Sander Marechal


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]