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] Summary and Focus?


--- On Fri, 6/20/08, Sander Marechal <sander.marechal@tribal-im.com> wrote:

> From: Sander Marechal <sander.marechal@tribal-im.com>
> Subject: Re: [oiic-formation-discuss] Summary and Focus?
> To: hozelda@yahoo.com
> Cc: oiic-formation-discuss@lists.oasis-open.org
> Date: Friday, June 20, 2008, 5:18 AM
> jose lorenzo wrote:
> > --- On Thu, 6/19/08, Shawn
> <sgrover@open2space.com> wrote:
> >> 3. Are we testing how to use ODF to interact with
> other formats
> >> (OOXML, CDR, etc.)
> > 
> > Rob (that I remember) has stated that he has been
> approached with
> > those requests. I think that is within scope but of
> lower priority to
> > cleaning house to some extent so that ODF itself is
> better.
> > ODF-only/mostly inter-app interop seems to be getting
> more votes by
> > more people than inter-protocol interop; however, if
> (eg) marbux and
> > others have contributions to make on interop with
> other standards, I
> > think that will carry weight.
> 
>  From what I read, Marbux's hammering on CDRF
> doesn't have anything to 
> do with inter-protocol interop (i.e. between ODF, OOXML,
> XHTML, 
> etcetera) but with interop inside the ODF universe (i.e. a
> way to make 
> sure that if the TC creates interop profiles, that those
> profiles 
> actually provide interop). See 
> http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00353.html
> 
> Marbux wrote:
> > I.e., an implementation of an ODF desktop word 
> processor profile
> > (more featureful) that opens a document generated by
> an implementation
> > of a subset ODF web app editor profile (less
> featureful) would process
> > the document as though the latter were the superset.
> The document can
> > then be edited in the more featureful app and sent
> back to the less
> > featureful app in a vocabulary the less featureful app
> can understand
> > and process correctly.
> 
> Simon pointed out to me that what CDRF defines as profiles
> is something 
> different than a subset profile that could be used as an
> interop 
> specification, but the idea itself has merit I think, even
> when it's got 
> nothing to do with CDRF.
> 
> So, if you filter out the CDRF stuff from the list, how
> much call is 
> there for interop-between-different-standards?

I didn't specify "profiles" and "CDRF" at the exclusion of everything else. Marbux and others (including Rob) have collectively mentioned numerous times the goals of interoperating with (eg) W3C standards. OOXML has even been mentioned (by marbux, especially early on, directly as well as indirectly, and by others). And let's not forget that I am not excluding myself from this list.

I singled out marbux because, at the time I wrote the above, he had said he had some things to share if we were interested, because he has talked about interop with other W3C standards (though he later clarified that it was mentioned as an example), because the CDRF he is championing was intended to help in the task to have the many XML protocols interoperate (so interop with other protocols is at least implied since it is facilitated).

He wrote this: http://docs.google.com/View?docid=ddxc4vcm_181dzcw64 which is an attempt to clean up parts of ODF (version 1.2 draft 2).

"10. There are no rules regarding the elements and attributes that actually have to be supported by conforming applications, except that applications **shall not** [ed: ODF 1.2 dr 2 states "should not" instead] use foreign elements and attributes for features defined in the OpenDocument schema. See appendix D."

I would say that some profiles SHALL NOT allow extensions while other profiles SHOULD NOT or COULD etc. Those most desiring of interop would opt for apps that conform at the higher levels (ie, prefer a SHALL NOT profile over SHOULD NOT profile).

Also, in this attempt to clean up the beginning of ODF, he solves the "MAY" problem the easiest way possible, by essentially returning to the rfc 2119 definition of MAY (which includes a requirement for conformance). This is done by the statement made at the top, presumably a similar statement was dropped when OASIS ODF v1.0 went to ISO (as he has stated).

Anyway, I used "10." to re-emphasis a quick point I've stated before about profiles and to show one example of the various on that page that marbux has written to improve ODF interop. I see these as a positive and possibly necessary set of changes required of ODF in order to close loopholes. This is the sort of thing that I think is necessary to be done to toughen ODF, but a framework based on profiles would likely mean that this whole section would have to be rewritten since we might want to differentiate profiles also by their ability to adhere to more strict requirements than others. We might then, at a minimum, want to reorganize the section a little to allow the SHALLs, COULDs, etc, to be more easily included in a way that is more modular and dependent on the profile to which they apply.



      


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