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

On Monday 30. June 2008 23:56:00 Peter Dolding wrote:
> >> So, the point I'm trying to make here is that if we want to have ODF
> >> working
> >> across a large range of usecases having a simple metric of rendering or
> >> of preserving doesn't make much sense. It would likely just hamper
> >> uptake since
> >> the most exciting usecases would not be able to claim ODF compliance.
> >
> > It is a balancing act.  In a sense, the ODF TC can define conformance
> > however it wants.  We can have a very loose definition that makes many
> > applications conformant.  Or we can have a very strict definition that no
> > existing ODF application can pass.  I don't think it makes sense to
> > define conformance for ODF to be such that only heavy-weight, traditional
> > desktop editors can claim conformance.  Doing so would risk leaving out
> > the most interesting and vibrant part of the market today.
> This is exactly why I said TC should not be headed by implementers.
> But by neutral organization.    We cannot care if everyone fails.
> Look at the html acid tests when they were released not one rendering
> engine passed.

I'm not sure if you replied to what rob wrote (2nd level indent) or what I 
wrote (3th level/top) but if you replied to me then I'd like to clarify one 
The point I was trying to make is that a different usecase of ODF requires 
vastly different set of features.  Where the difference between supporting 
and round-tripping are separate as well.
Requiring that a odf-viewer round-trips perfectly means it will fail all tests 
since it would never save.

So, putting your doubt in rob and/or me seems incorrect in this subthread as 
there is no giving of a helping hand to crippled implementation. It is about 
having the test-results fine-grained enough so we end up with a way to give 
an implementation great marks for reading ODF and be able to detect bad 
round-tripping in this office implementation.

Hope that clears things up ;)
Thomas Zander

This is a digitally signed message part.

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