Slashdot Mirror

Why Yet Another Crypto Library instead of a more widely used one?

If you're referring to DSS then they probably mean that the bug bounty applies to the esig library or the standard it is based on. It's a convenient tool for applying and verifying EU-compliant document signatures (PDF, XML, ASiC) throughout EU institutions.

A contrived use case could be that you want to sign a legally binding contract with a Spanish bank to own a summer house, but you authenticate yourself with your Finnish bank, and the Spanish bank has outsourced the signing service to a company located in the Netherlands. But anyone involved can validate the signed document and see who were involved.

you are kidding, right? or just ignorant? or maybe one more shill?

ODF is a official standard, older than OOXML, simple, consistent and very well documented:
https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...
https://docs.oasis-open.org/of...

OOXML on the other hand, was heavily pushed by MS to be a standard and only got approved by using very shady tactics. The format have fields of "closed binary" blobs for "compability" reasons and is not even correctly used by MS office, as their documents fail to pass the standard validation tools. The format is also extremely complex (that is why it needs 6000+ pages spec) and have patents (MS promises to not sue anybody due to this... but this is MS and history show that it can be trusted). Finally, it uses embedded objects in several formats that only exist in windows, instead of already existent standard format objects. Everything to lock up the format to windows and MS office, even if the format is (almost) "open"

https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...

Mnemonic operators are coming back in REST and other URL-based APIs. For example in OData v4: http://docs.oasis-open.org/oda...

Does JSON support namespaces? AFAIK it doesn't, and that would seem to make it suitable only for fairly simple data interchange and not really scalable. As far as which is best visually... XML is a bit wordy/busy, especially if it uses a lot namespaces, but it's a pretty minor problem given that with both XML and JSON, it's a piece of piss to write a nice visual editor. The important thing for me is having a solid platform for building applications, and XML has the capability and maturity for that - even if it is a bit ugly!

I know it's bad-form replying to my own post, but it does appear that there is some kind of namespacing going on in the OData spec. Does anyone know if this namespacing is part of the JSON standard, or is it just a convention that OASIS are using?

Eitherway, I still prefer XML! :D

At the link for the specifications OData JSON Format Version 4.0

The documents that are tagged as Authoritative are .doc, not even .docx

I agree with most of what you have written.

I think the key thing for organisations is to have a format (such as the OpenDocument format, otherwise known as ISO 26300 see: http://iso26300.info/ and https://www.oasis-open.org/com...) that is a standard that:

(1) allows documents written now to be read correctly in 30+ years time

(2) anybody can legally implement without have to pay any kind of licence fee, or other form of fee

(3) will allow documents to be read & edited by any software that adheres faithfully to the standard

(4) can represent what people need to do in a document without having to pay a large fee for the privilege and without restricting people to charge a hefty fee should they so desire

So a lot of the value of the OpenDocument format is to the organisation itself, and other organisations it interacts with. In fact it is of value to individuals as well. Also of prime importance, no company can hold peoples documents to ransom by locking them into a proprietary format - like Microsoft attempts to do.

Note that Microsoft is entitled to fully implement the OpenDocument format and to charge whatever it wants for its software, so it cannot validly complain it is being locked out of markets - if it refuses to properly implement the OpenDocument format!

The fact that most people only use a very small subset, and that this subset is within the OpenDocument specification is important, as this means that people should not need extensive training to create and distribute documents that can be used by other people with different software.

LibreOffice is just one of many pieces of software (http://en.wikipedia.org/wiki/OpenDocument) that is committed to the OpenDocument format.

"In other words, as I said on that occasion: choosing open standards is a very smart business decision."

(http://europa.eu/rapid/press-release_SPEECH-10-300_en.htm) in 2010.

So this is basically the same as UDDI [wikipedia.org] for WSDL?

Its similar to UDDI or WS-Discovery in that it provides a service discovery mechanism.

Its dissimilar to them in that it also includes a JavaScript API for calling a service.

Its even more dissimilar in its lack of complexity.

Compare:
Web Intents
UDDI
WS-Discovery

http://www.oasis-open.org/specs/

Please point out the spec that defines how to do formulas. Oh? You can't find it? You know, you are right, it seems to be oddly missing. Now it's going to be real hard to make a clean room office suite with no standard on how to do formulas. I guess we can make a giant table where you can only type in numbers. We'll just leave out the more exotic things like adding, subtracting, summing, ranges, etc into a later version.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office-formula

1) C++ and ODF are considered open by FOSS proponents because they are royalty-free standards which can be implemented in Free software. H.264, on the other hand, can't because the H.264 licensing doesn't allow the software developer to convey the same rights to the client that the developer has. From that standpoint, you are completely in error. Additionally, you can join OASIS and contribute to the next version of the standard. The link to join is on OASIS Open Document Format for Office Applications (OpenDocument) TC. Finding it took one Google search.

2) The WebM and VP8 standard isn't being developed. It is final. Implementations continue to improve, though, both through Google Code channels and through independent ones. You're welcome to join any of those efforts.

In short, you're cocked up. I'd go so far as to say "spreading FUD."

OpenDocument Specification: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#odf11

Yes, ODF 1.2: It's been worked on since 2007 or so and now in the stage "public review of committee draft" (here (as PDF, replace .pdf by .odt for the ODF). AFAIK, next stage is "committee specification" and that sounds like it's nearing completion.
The formulas are in a separate (IMHO well-written and useful) sub-spec called "OpenFormula".

>(the up to date version of ODF is 2.0).

No, 1.1 is the current version, 1.2 is being worked on and it looks like it ought to be finished this year:
http://lists.oasis-open.org/archives/office/201001/threads.html

XML Provides Standardization for International Functionality between individuals and (within) businesses, governments.... XML Customization by Businesses, Governments, Individuals... altering recognized and accepted international XML Standards seek to hawk proprietary products and hook data/content novices into a blind and costly ally.

W3C XML http://www.w3.org/XML/
ODF XML ISO/IEC 26300:2006 http://www.iso.org/
ODF XML OASIS http://www.oasis-open.org/
OpenOffice XML http://www.openoffice.org/

The XML OpenDocument Format (ODF) standard, used by OpenOffice and others, is an open XML-based document file format for office applications to be used for documents containing text, spreadsheets, charts, and graphical elements. The file format makes transformations to other formats simple by leveraging and reusing existing standards wherever possible. As an open standard under the stewardship of OASIS, OpenDocument also creates the possibility for new types of applications and solutions to be developed other than traditional office productivity applications.

IMO Summary: If you fear long-term data/content cost/legal..., then... from Microsoft Office... RUN AWAY! RUN AWAY FAST!

Actually, the OpenDocument specification explicitly covers two possibilities: OpenDocument packages, which are zip files containing an XML document, a manifest, and other ancilliary files, and a single XML document, which contains the whole document in one XML file. See section 2.1 of the spec.

Yes. I've read it before. Other than one part that is false, the rest is hand waving.

It basically says "Yeah, we know the standard doesn't specify so much stuff that the only way to be compatible is to get people to agree on how to do things.."

That's not "interoperability", that's "praying" everyone manages to make it work.

The part about section 8.3.1 is completely bogus. Read the specification yourself. 8.3.1 says nothing about requiring brackets.

http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html#8.3.1.Referencing%20Table%20Cells|outline

It says:

"To reference table cells so called cell addresses are used. The structure of a cell address is as follows:

1.The name of the table.

2.A dot (.).

3.An alphabetic value representing the column. The letter A represents column 1, B represents column 2, and so on. AA represents column 27, AB represents column 28, and so on.

4.A numeric value representing the row. The number 1 represents the first row, the number 2 represents the second row, and so on."

Nothing there about brackets.

Which conveniently omits that ODF was submitted under PAS - the process for reviewing and approving something that's already a standard and is already in use. ODF officially started the standardization process in OASIS in December of 2002, starting from the StarOffice format.

As for OASIS's track record, I refer you to http://www.oasis-open.org/specs/ that lists the standards they've originated. These include DocBook and a large number of SOAP-related standards. That's hardly "no track record at all". And their heavy concentration in XML-based standards makes them a good place for another XML-based standard.

Rationale: This is the set of functions that are "widely implemented" by desktop spreadsheet applications. This was originally computed by starting with the small group, and adding functions that were implemented by at least 4 of the following applications: Excel 2003, Gnumeric, Lotus 1-2-3 v9, OpenOffice.org 2, and QuattroPro 12. Some effort was made to identify translations (e.g., where the same function has a different name). Per December 2006 discussion the following were moved from âoeLargeâ to âoeMediumâ: ACOT, ACOTH, COT, COTH (since other trig functions were in medium, it was inconsistent to keep these in âoeLargeâ).

Then from december 2008 to now, most changes I looked at were improved comments for the test case scenarios.
What I'm getting at is that, had Microsoft wanted to implement ODF 1.2, they could have already made experimental MS Office code last year, gradually adapting it with the further amendments and changes in the OpenFormula spec. This wouldn't have interfered with their stated target, ODF v1.1 compliance (because ODF 1.1 doesn't specify the formulas, except for their general syntax).
And *THEN* they could say, while delivering Office 2007 SP2, that it is only guaranteed compliant with ODF v1.1.
They could make the last modifications while the ODF committee draft's changes are implemented circa end 2009, so they can sell it as "now also ODF 1.2 compliant" Office 2007 SP3 in 2010.

Rationale: This is the set of functions that are "widely implemented" by desktop spreadsheet applications. This was originally computed by starting with the small group, and adding functions that were implemented by at least 4 of the following applications: Excel 2003, Gnumeric, Lotus 1-2-3 v9, OpenOffice.org 2, and QuattroPro 12. Some effort was made to identify translations (e.g., where the same function has a different name). Per December 2006 discussion the following were moved from âoeLargeâ to âoeMediumâ: ACOT, ACOTH, COT, COTH (since other trig functions were in medium, it was inconsistent to keep these in âoeLargeâ).

Then from december 2008 to now, most changes I looked at were improved comments for the test case scenarios.
What I'm getting at is that, had Microsoft wanted to implement ODF 1.2, they could have already made experimental MS Office code last year, gradually adapting it with the further amendments and changes in the OpenFormula spec. This wouldn't have interfered with their stated target, ODF v1.1 compliance (because ODF 1.1 doesn't specify the formulas, except for their general syntax).
And *THEN* they could say, while delivering Office 2007 SP2, that it is only guaranteed compliant with ODF v1.1.
They could make the last modifications while the ODF committee draft's changes are implemented circa end 2009, so they can sell it as "now also ODF 1.2 compliant" Office 2007 SP3 in 2010.

It is "in the pipeline"; it's presumably not going to change very much more. So both MS Office 2007 SP2 and ODF 1.2 could have "converged" so to speak. I mean, surely that's a reason why they are members of the OpenDocument TC of OASIS.
An earlier posting by Rob Weir (february 2009): ODF 1.2 committee draft 1
Microsoft announced MS Office 2007 SP2 in april 2009; I do understand that it takes time to implement a large standard :-)
<dream-on-mode>
Now I hope MS will announce they'll support ODF 1.2 in their upcoming Office 2007 SP3, don't buy SP2 in the meantime because it's incompatible.
</dream-on-mode>

Let's see what the ODF 1.1 standard says in section 8.1.3 (Table Cell):

Addresses of cells that contain numbers. The addresses can be relative or absolute, see section 8.3.1. Addresses in formulas start with a "[" and end with a "]". See sections 8.3.1 and 8.3.1 for information about how to address a cell or cell range.

So, addresses are enclosed in square brackets. Now look at what Rob Weir found:

So, going back to my test spreadsheets from all of the various ODF applications, how do these applications encode formulas with cell addresses:

• Symphony 1.3: =[.E12]+[.C13]-[.D13]
• Microsoft/CleverAge 3.0: =[.E12]+[.C13]-[.D13]
• KSpread 1.6.3: =[.E12]+[.C13]-[.D13]
• Google Spreadsheets: =[.E12]+[.C13]-[.D13]
• OpenOffice 3.01: =[.E12]+[.C13]-[.D13]
• Sun Plugin 3.0: [.E12]+[.C13]-[.D13]
• Excel 2007 SP2: =E12+C13-D13
  I'll leave it as an exercise to the reader to determine which one of these seven is wrong and does not conform to the ODF 1.1 standard.

Note especially the difference between the Microsoft/CleverAge plugin for MS Office and MS Excel 2007. The CleverAge plugin is *older*. They could have re-used it (why do the work again?).
I just checked, and the committee draft ODF 1.2 has the same requirement (par. 17.645 search for table:formula).

I think a test suite is a wonderful idea, and work in this area is already underway at the OASIS ODF Interoperability and Conformance TC, of which Microsoft is a member. However, a test suite is a tool for a vendor to check for bugs in their implementation, for errors that were accidentally introduced. It doesn't solve the problem of a vendor knowingly and intentionally introducing incompatibilities into their implementations, which apparently is what we have going on right now. It isn't like Microsoft failed to notice that SP2 corrupts spreadsheets created in every other ODF spreadsheet application. A test suite can take us to the next level of interoperability among ODF vendors seeking interoperability, and we should do it for that reason. But, by itself, a test suite cannot prevent a willful attempt by a monopolist to disrupt interoperability.

You do realize that the "OpenDocument Foundation" has no practical responsibility for the OpenDocument format, right? OASIS is responsible for the format, and the "OpenDocument Foundation", before it was defunct did little more than name-squatting on OpenDocument.

While docbook can be good for a small setup it tends to be overly simple when working with large documents. I'd suggest instead using DITA as it allows for the types of referencing mentioned and also allows for pretty extensive reuse of content. Like docbook it can be transformed into most formats you may need but gives the added bonus of being able to break it up and re-organize the book structure dynamically (this is really how technical writing should be).

A good resource for how to use this powerful language can be found at http://dita.xml.org/. As the parent suggested <oXygen/> for XML is a great editor for this kind of work and comes with a DITA edition.

Also as the parent suggested svn is really the best way to go for revision control but a database like eXist can be a great resource management tool for your content while your working with it.

I'm a retired lawyer. This really sounds like a screwup, not a scandal. The language under discussion refers to "services" not to "software" but it's a EULA for software.

My guess is that some lawyer got behind schedule, had more adrenaline going than grey matter trying to meet the deadline, and accidentally copied and pasted the wrong paragraph from the wrong document into the wrong document that was open at the same time. Or copied too much and didn't notice it.

There are a lot of copy and paste operations in law office contract work because it takes lots of time to research legal requirements. Contract language that has already been vetted at the law library is often too valuable to waste by reinventing the wheel every time you need the same term. Contracts are often more copy and paste than original.

Abraham Lincoln said that a lawyer's reputation is his biggest stock in trade. Others say it's the size of the law firm's collection of legal forms. Short story: There's lots of content recycling in the law office.

A lot of law offices go beyond copy and paste take another tack and use profession-specific document assembly software. With some, you select from optional paragraphs for a selected kind of contract. A careless mouse click and you get the wrong paragraph.

If anyone is in the mood to develop it, we still don't have that kind of open source software available and there's a market for it. There's even an XML open standard developed by the legal profession for that kind of work that's languishing for lack of implementations. See the spec at the OASIS eContracts Technical Committee. Designed to be used in conjunction with existing XML document word processing formats, an extension of UBL.

Anyway, I suggest standing by seeing what Google has to say about it. My guess is that there's going to be an apology for a screwup and a new EULA substituted in short order.

It's all too easy to underestimate how many interruptions you'll have and get behind on meeting a deadline, then foul up in the rush to get the document out the door on time. Last minute changes play their part too.

Lawyers are susceptible to human error, just like software engineers. In fact, at least one lawyer is wrong in just about every case. :-) I doubt there's any real scandal here; Just another human being doing what human beings do best, making a mistake.

Paul E. Merrell, J.D.

You mean something like this?

>The ODF spec says that,
>
>"An implementation shall be accompanied by a document that defines all implementation-defined and locale-specific
>characteristics and all extensions."
>
>(emphasis mine)

Could you direct me to were one can find that specific text in the spec? I tried to search for it but could not find it. I looked at the spec here:

http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html

Do I need to look elsewere to find it?

"IBM has 2 people on the payroll who's sole purpose is to trash OOXML (Rob Weir and PJ)."

Incorrect. Rob Weir is also a contributor to the ODF specification (see appendix H here and is co-chair of the OASIS Open Document Format for Office Applications (OpenDocument) Technical Committee, so he does more than just "trash OOXML."

I think I get what you mean with irregular tables. Paragraph 8.1 says

Table rows may be empty, and different rows might contain a different number of table cells. This is not an error, but applications might resolve this in different ways. Spreadsheet applications typically operate on large tables that have a fixed application dependent row and column number, but may have an unused area. Only the used area of the table is saved in files.

I don't know what you mean with ink.

BTW, there was an effort to include Microsoft Office features into ODF, but Sun explicitly rejected it, saying that ODF should not go beyond StarOffice/OO.o features.

Even if Sun played nasty in OASIS, which I can't comment on because I'm an outsider, don't you think that a lot of new companies suddenly could have joined the OASIS Office committee who all miraculously voted in favour of these Microsoft Office features? I'm sure a way would have been found, and it would have been cheaper than lobbying 87 nations. Without the approval vote of Kazakhstan, CÃte d'Ivoire, and Trinidad and Tobago OOXML wouldn't have passed :-(

BTW: why does it say "Status: deleted" (with an icon of a garbage can) on the ISO 29500 page? I must be hallucinating.

ODF also lacks the ability to embed OLE objects as XML. ODF only stores OLE objects as binary blobs, while Microsoft OFfice allows OLE object to be stored as XML is possible (and binary blobs if not). This makes it possible to traverse a hierarchy of embedded OLE objects using XML parsing.

ISO OOXML uses a single format for spreadsheet dates (the ISO standard), while ODF uses 3 different date formats.

Um.. from ECMA's disposition of comments, about OOXML's 1900- and 1904-based dates:

Regarding the requests that we adopt a single date base, we do not see this as a viable option given the corpus of existing binary documents requiring support for the existing 1900 and 1904 date bases.

I think I'll stop answering your points now.. I'm tired.

Yes you can download the spec for SWF, but nowhere in the spec did it discuss terms of use.

If I implement to their spec, are they going to sue me because of the patents that cover the SWF technology? They say it is available as an "open specification", but there's nothing that says if there are any restrictions on my use of the specification.

Do they have a covenant not to sue like the one that Sun has, the one that IBM has or even the one that Microsoft has?

Until such time as ISO can put in safeguards against such blatant abuse, have leadership which will follow their own directives, have a mechanism which will keep the process transparent, discipline P members that vote only when they want, restrict countries becoming a P member just by sending in a letter i.e Jamaica, Cyprus, Malta, Kazakhstan, Lebanon, Azerbaijan, Cote-d'Ivore and others a week before a vote with no review in their county, ISO cannot deliver a true Open Standards. Its time for the community to rally behind http://www.oasis-open.org/ with the exception of W3C, OASIS is the only organization delivering true Open Standards today and the membership it not restrictive.

If you're looking for "compromises", you should look at OOXML, not ODF. Rob Weir shows that OOXML is full of a massive number of errors - I estimate over 172,000 unresolved errors. These comments about ODF are without merit; OpenDocument can handle change requests (see, for example, section 4.6) and tables in presentations. OpenDocument 1.0 handles tables-in-presentations just fine, they're just encoded differently than you seem to be expecting. Embedded tables are encoded as embedded spreadsheets; this is slightly different than how OOXML encodes it, but all the data and capabilities are there. OpenDocument 1.2 will make the indirection optional, but this is all invisible to end-users anyway. Note that this means that tables CAN be in presentations, but more importantly, they're encoded the same way that they are encoded in other kinds of documents - OpenDocument has a single, clear table model. In contrast, OOXML has multiple incompatible table models. OpenDocument is remarkably consistent, as well as building on well-established standards - which is why it can be so much smaller, and so much more capable, at the same time.

Sure, many office suites will implement some subset of OOXML. But it would be wise to view it as a temporary transition format, so that you can escape from vendor-specific formats to an open standard like ODF. Yes, it's convenient to have it as a "published standard", but Ecma is enough for that; there's no reason to have an ISO stamp on it. OOXML is essentially the proprietary format of a single vendor. There's no reason to confuse anyone into thinking it's some sort of universal format, and the ISO stamp is likely to cause that kind of confusion.

The format for documents should not be controlled by any single office document supplier. That is a key reason why OOXML should be rejected by ISO, and published only by Ecma as some sort of interim format (to enable people to move off it). OOXML is also so error-ridden that it should have been laughed out of the fast track process.

http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf

OOXML:

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%201%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%202%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%203%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%204%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%205%20(PDF).zip

Ok... i tried to find out who this guy is. Open Document Format editor? I see no reference to him anywhere on the ODf pages. http://www.oasis-open.org/home/index.php. I see nothing on his website that has anything to do with ODF. All I see is MS fanboyism. This sounds a lot like that other "news" story that was going around where a "open Document format" closes up shop and says the ODF format is no good... and it had nothing to do with ODF just more FUD. Can anyone see how/why he is the Open Document Format editor?

I always though that sign looked like a twisted female symbol -- "" http://www.oasis-open.org/docbook/xmlcharent/glyphs/100dpi/U2640.png

Because it seemd a good idea at the time. But, people are learning from that.

As I comment above, the trend now is to use URNs intstead of URLs for XML Namespace URIs now. See http://www.oasis-open.org/specs/index.php and notice how the earlier ones have namespaces like "http://docs.oasis-open.org/ws-tx/wscoor/2006/06" (for WS-Transaction 1.1) but the most recent ones have things like "urn:oasis:names:tc:xliff:document:1.2" (for XLIFF 1.2)

URNs don't have anywhere near enough information to download with; no matter how hairbrained the programmer gets, they can't think it's a download location. You can still validate these, but the validating program has to know where the file is that maps to that URN namespace; hopefully it comes *with* the program instead of being a hard-coded URL.

Programs should really come with a bundled copy of these schema files to validate against.

My original comment:
http://developers.slashdot.org/comments.pl?sid=447350&cid=22362548

Similarly, nothing in this statement is intended to relieve Sun of its obligations, if any, under the applicable rules of OASIS.

And this statement in Sun's license disagrees with you. Remember that ODF 2.0 woudln't be a new specification, it'd be a new version of an existing specification. And patent grants are for the specification, not any particular version of it. See the OASIS IPR document, particularly section 11.1 which says that a contributor or participant is permanently subject to their contributor or participation obligations even after they withdraw from the TC, and 11.2 which says they're permanently subject to those obligations even if they withdraw from OASIS completely. The obligations, and the grants, don't retroactively disappear just because a new draft is issued or a new version approved.

In short, Sun can withdraw rather than license their patents to OASIS but they can't withdraw license grants they've already, by earlier contribution or participation, been obligated to give. In shorter, OASIS rules say "No take-backs.", and Sun agreed to be bound by those rules and they say so right in their covenant.

I did this because there is already a fully supported, open, non-patent-encumbered standard covering the whole domain of what ooxml proposes

False. ODF has the exact same sort of patent problems that OOXML does. In fact, ODF is in worse shape because Sun's IPR grant is only valid so long as Sun participates in the ODF committee.

http://www.oasis-open.org/committees/office/ipr.php

For the User/Developer, among the best are ... "Open".

Apache FOP: http://freshmeat.net/projects/fop/
Apache FOP: http://xmlgraphics.apache.org/fop/download.html
    NetBeans: http://download.netbeans.org/netbeans/6.0/final/
    Alfresco: http://www.alfresco.com/

Good Guide: http://www.vrcommunications.com/PDFs/ditaotug141-03122007-pdf.pdf
Title DITA Open Toolkit User Guide: Fourth edition, December 17, 2007. Based on release 1.4.1 of DITA Open Toolkit. All files copyright 2006-2007 by VR Communications, Inc., unless otherwise indicated. Licensing Edition, release, copyright and usage of this document and related materials is regulated by a Common Public License (CPL) granted by OASIS (Organization for the Advancement of Structured Information Standards), http://www.oasis-open.org/ . DITA Open Toolkit is an open-source, reference implementation of the OASIS DITA standard (currently DITA 1.1).

JAVA: http://www.java2s.com/Open-Source/Java/CatalogJava.htm
Open Office: http://www.2008-official.com/openoffice/

Actually, Sun does have absolute control over ODF. Apart from the fact that Sun employees are not only the chair of the committee, but make up nearly half of the committee members, the OpenOffice file format that was donated to OASIS, and is the basis of ODF, was licensed under the strict provision that Sun only licensed their patents (or rather promised not to sue) to ODF implementors as long as they continued to participate in it's development.

So, if Sun doesn't like what OASIS is doing (hardly possible given the sheer numbers of people on the committee, but still), they need only threaten to walk away and effictively kill any future version ODF if they don't get their way.

see http://www.oasis-open.org/committees/office/ipr.php and note particularly the clause that contains this phrase: "or of any subsequent version thereof ("OpenDocument Implementation") in which development Sun participates to the point of incurring an obligation"

No no no. ODF is an *OASIS* standard. Sun does not control it:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

Please can we get this clear:

ODF != Open Office.
File formats != Applications.
Open Information Standards != Open Source Software

Not true. While Sun "indirectly controls" the development of OpenOffice.org, the file format is owned by Oasis, which is a "not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society" (according to their own website). Although Sun is a member of Oasis, it's not alone there, so Sun will never be able to hijack the file format all by themselves, because the other members won't allow it.

Among the other members of Oasis is IBM, which, with its Lotus Symphony office suite, has interest in ODF as well. So, for the sake of the argument, IBM has as much interest and power to control ODF as Sun has. But none of them can do anything without the consent of the other (and even other members), since the file format is not owned by any of them.

Oh, yeah... ODF doesn't support, for instance, the enterprisey feature of autoSpaceLikeWord95.

It's completely BS that ODF doesn't support what enterprises need. This is just the kind of FUD that Microsoft tries to push. They include new "features" in their office suite (and all their software) and sell them as "what the enterprise needs", when in fact it's just to increase the lock-in. I'm glad to see that most enterprises are starting to look at Vista and Office 2007 for what they're worth, they're seeing that it's not worth to upgrade, and they're starting to look at alternatives.

What are these features that "enterprises need" anyway? VBA? It's going away in Microsoft as well.

The worst part about this "standard" is the license: it is packed in a Windows-only executable package and is licensed for noncommercial use on Windows machines only.

I've done that, and if you weren't able to make it work, I suggest you read a little more about the standard.

I'm in the process of writing an app that modifies existing spreadsheet and documents to add new data automatically.

ODF is easily an order of magnitude simpler to create and modify than any Microsoft format.

It's why I'm putting a big effort into promoting ODF and fighting MSOOXML. If ODF becomes the defacto standard, my job becomes massively easier and my profitability leaps.

>So when is Sun going to turn control of ODF over to a standards body?

The ODF spec is managed by OASIS and approved by ISO. I understand that Sun had no more control than any other party on the OASIS committee.

c.f. http://www.oasis-open.org/committees/membership.php?wg_abbrev=office

I saw this blog from one of the current chairs of the ODF committee in OASIS: http://www.robweir.com/blog/2007/12/bait-and-switch.html

So, ODF was adopted as an ISO standard about a year ago, and since then there has already been a new version of ODF (1.1) released by OASIS, and they are supposedly close on version 1.2. I believe 1.2 is supposed to be significant as they've promised it will include a formula definition for spreadsheets (although the working group hasn't seen much activity lately if you look at the mailing list archives: http://lists.oasis-open.org/archives/office-formula/). So, the maintenance of ODF right now is being handled solely by OASIS, and I'm not sure what their plans are for bringing new drafts to the ISO.

Now, one of the Chairs of the ODF committee (IBM and Sun are now co-chairs of the ODF committee) has a blog post saying that Microsoft is somehow pulling a "bait and switch" because Ecma has proposed to ISO that a joint maintenance agreement be set up once DIS 29500 is approved. We're still months away from approval, but TC45 has already reached out and tried to start a discussion around maintenance.

So it's been a year since Rob's committee had its ISO approval and has since then maintained sole control; and TC45's DIS 29500 still has a few months before approval and they are already trying to establish a maintenance agreement. And this is now called a "bait and switch"?

That's my Weird Moment of the Day.

The ODF (that would be Foundation) was never in charge of the ODF file formats. They just had a confusing name. The ODF format was created by OASIS