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] My perspective

Thomas Zander <zander@kde.org> wrote on 06/30/2008 05:28:23 PM:

> >
> > I think of a profile (or at least one kind of a profile) as a
> > specification that records a set of "feature-groups" that together solve a
> > recurring problem.
> Any sort of grouping to make this more useful for the end user sounds sane, I
> was more assuming market values would sort this out for us.  A magazine for a
> specific set of users may use our testresults to recommend somethingto their
> readers.  I'm not sure that defining profiles is actually solving anything. I
> would not go further then to conclude it makes the problem more manageable
> for people. That naturally is a good thing, but I think we have to attract a
> different set of people to OASIS to actually come up with proper profiles.
> You and me (as to backers of our implementation) are probably the worst
> possible people to come up with good profiles. Actual users in actual
> usecases probably are much better at that.

I believe that a TC with broad participation from vendors is one way in which the market sorts these things out.  

A profile is a form of "variety reduction".  If I had N vendors, each one supporting its own subset of the ODF standard, then interoperability becomes quite difficult, especially when you consider the range of implementations from cell phones to web to desktop.  But if the vendors agree on an ODF/Mobile and ODF/Web profile, and these are implemented completely by the corresponding vendors (a big if), then we go from N different subsets to only 3.  You see similar things happening with XHTML and XHTML Basic, or C++ and Embedded C++.  You also see it in proprietary technologies, like ODBC Level 1 versus ODBC Level 2.

Of course if we end up with as many profiles as we have implementations, then we have not really accomplished anything.

I agree with you that it would not make sense for you and I (representatives of desktop editors) to define an ODF web profile or mobile profile.  We would want vendors with products in those areas to take the lead in defining these profiles.    


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