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: Implementation vs. result (CDRF, profiles, et al.)


Although it's been hard work keeping up, I have read everything :)

I think we need to focus on what this new TC is seeking to achieve, not how it will decide to achieve things. In particular, specifying in too much detail what its outputs should be, or what format it outputs should be in, is extremely dangerous. What we want/need/desire is great interoperability between ODF implementations (for some definition of such). Tying things down too tightly could mean the TC is constrained into not pursuing other avenues which achieve that goal.

As an example, this talk of CDRF I find very confused - it has virtually nothing to do with interop or conformance. CDRF specifies how you can mix different format documents in a single document, e.g. HTML and SVG. You can use CDRF with ODF (it's just XML after all), but it gives us nothing in terms of interop - the TC is looking at ODF interop only, not mashing together (for example) ODF and HTML, as far as I understand it.

Also, I worry about trying to find too precise a definition of "profile", which doesn't seem to be focussed on the result. As I understand it, the utility here is being able to say "you don't have to implement all of ODF; you could implement these small parts, and here's how your app can deal with the bits it doesn't know without trashing the document". Surely that's what we want the TC to enable, without saying exactly what a profile ought to be in order to enable that?


Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

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