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. Extensions


--- On Thu, 7/3/08, Simon Calderson <caldersons@yahoo.co.uk> wrote:

> From: Simon Calderson <caldersons@yahoo.co.uk>
> Subject: Re: [oiic-formation-discuss] My perspective. Extensions
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Thursday, July 3, 2008, 4:57 PM
> Ben Baston <bbaston@gmail.com> wrote:
> > Though I accept your guidance that changing the
> current ODF treatment of extensions

...

> In general, this new TC must act on the basis of good
> faith. It cannot outlaw what people will do with the
> standard, or prevent them doing "bad" things, and
> its role as a watchdog of sorts is something I would contest
> in any event - it is much more useful as a tool for vendors
> than some kind of quasi-W3C.

The young ODF market should be helped to achieve interop. The assumption is that the market is cooperative. Potentially, there might be many players, most of which won't have the resources of an IBM or Microsoft, and I think these will be most helped with all the official guidance on testing that OASIS can provide.

There is disagreement on the list over how likely are we to end up with zillions of foreign tags if little is done to reign them in or if their proliferation is encouraged.

I think we should encourage growth, but if OASIS does not build in some way to manage the growth and identify different levels of conformance, someone else will.

There is always time later on for OASIS to take action to focus on problems that may arise, so I am not that worried; however, I do think that both short and long term goals will be advanced by continuing to make the ODF spec language as unambiguous and clear as possible.

I also think the proposed OIIC TC needs to have in scope all of the various issues that may affect interop even if short term it chooses to put greater emphasis on some things over others.

I don't know what "quasi-W3C" means. If it's important to know it, could someone elaborate?

> The comparison with HTML keeps being made in such
> discussions. ODF is totally different to HTML. For one
> thing, few people author ODF - a few select applications do
> it. It is much more important for those applications to be
> authoring good ODF than it is to stricture ODF in such a
> way that you can validate documents and call them
> "good" or "bad".

Maybe what you mean by "quasi-W3C" is a focus on correctness and less on helping out vendors? [I'm guessing this is what you mean.. though I believe W3C does have reference implementations.]

ODF vs. HTML: I don't see this vast difference you are talking about, but I admit to have much more knowledge of HTML than of ODF at this point in time. Would it truly be that difficult to create a "Hello World" ODF document by hand and then build on that? I haven't seen very much to make me think it would be so difficult.

I'll agree that into the next few years, likely, "it [would be] ... more important [to focus on getting] ... applications to be authoring good ODF than it [would be] to str[u]cture ODF in such a way that you can validate documents and call them 'good' or 'bad'." But why either/or? What pains you so much to imagine that some customers would be able to properly identify various levels of conformance?

I agree that putting a very low bar can make everyone happy, but I think many customers have and will be maturing to the point of demanding more. I don't think formats like, eg, OOXML will have many interoperable implementations from independent third parties. I think this interoperability among independent vendors will be an important attribute to have.

If order doesn't exist with ODF, the stream WILL get polluted. Rival formats gain BOTH by being more featureful and having everyone apparently conform AS WELL AS by having ODF fail at interop. It's virtually guaranteed that there will be uncooperative players. If these find loopholes, areas where the cooperative players assume friendliness and leave their guards down, they will be exploited to the max. Are we using rsh, telnet, and many other naive protocols today when exposed to the Internet? It's fine to look after the cooperative. Now, let's continue looking after them by making sure that they will have the ability to identify and stop trojans. It's naive to open yourself up to attacks. Hey, let's open up all sorts of services and the firewall. After all, it will help those trying to cooperate.

Anyway, forces outside OASIS might take the lead in identifying troublemakers. But if such help is not forthcoming and if pollution, trojans, etc become a problem for interoperability, then I am sure OASIS will react. If the carrot won't work, the stick will be swung at the most notorious implementations. If not ODF will give way to something else because I just don't see people standing by to see a worse format and worse ecosystem trounce ODF.



      


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