[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] Summary of some "profiles" usage and ideas
--- On Tue, 6/24/08, jose lorenzo <email@example.com> wrote: > From: jose lorenzo <firstname.lastname@example.org> > Subject: [oiic-formation-discuss] Summary of some "profiles" usage and ideas > To: email@example.com > Date: Tuesday, June 24, 2008, 1:00 AM > --- On Fri, 6/20/08, marbux <firstname.lastname@example.org> wrote: > > > From: marbux <email@example.com> > > Subject: Re: [oiic-formation-discuss] The importance > to users of documents looking the same > > To: firstname.lastname@example.org > > Date: Friday, June 20, 2008, 8:16 AM > > I just realized that I left a mental leap unexplained ... > [I still have to go through the "Profiles: suggested > use-cases" thread > http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00609.html > and surely I am missing a lot more material.] Another pov, from http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00679.html >> A practical way in which this would all help improve interoperability, would be if applications, when reading ODF, were able to read everything that the ODF standard allows, but when writing ODF, they should write conservatively, and aim to have their output documents issue no errors (of course) but also no warnings or notes. -- If we consider "ODF standard" above to be shorthand for (one or more) ODF profile(s), eg, ODF/core-X, then it highlights that reading and writing can follow distinct (levels of) profiles. More generally: an app can implement (adhere to) multiple profiles and follow any one of these during a prescribed scenario. Perhaps the choice is guided by a manual user settable mode/config or else based on configured or fixed automated interpretation of context. -- The above also actually *recommends* a particular approach: to read liberally but write conservatively (as IETF guidelines). This won't apply in all use cases, however. One more example and one that is somewhat at odds with round-tripping: -- an app working from (a mode of) a strict profile rejects or warns, etc, about documents that do not conform to its strictness. The issue is about not accepting deviations from the strict expectations. This is a great profile class for those users that want to have some added confidence that documents are not being invaded by foreign features outside of their configured settings (outside of the strict mode). This is very useful to many different groups under many scenarios.