PingBack from http://geeklectures.info/2007/12/26/novidades-open-xml-odf-interoperabilidade-e-outros/
O principal destaque do ETRM 4.0 é que o governo do estado de Massachusetts deixa cair o ISO ODF 1.0 (ISO 26300) do catálogo e adopta os standards OASIS ODF 1.1 (Não aprovado pelo ISO) em simultâneo com o standard ECMA 376 (ECMA Open XML)
Uma das razões centrais para a necessidade do upgrade e adopção da versão não ISO do ODF têm a ver com as limitações na área da acessibilidade do ISO ODF 1.0 que já são colmatadas e incorporadas no standard OASIS ODF 1.1
O OASIS ODF 1.1 no entanto foi rejeitado pelo ISO por não cumprir os requisitos de interoperabilidade ISO que apenas serão resolvidos no standard OASIS ODF 1.2 a submeter para votação/aprovação como ISO ODF 1.2 Standard em Fevereiro de 2008.
Document formats recommended by ETRM V4.0
The ETRM doesn't just recommend XML-based formats, however. It's a very pragmatic document that looks at the realities of current technology and trends, and it recommends six different document formats, each with well-defined areas of application. That list includes four formats in the "Open Formats" section (ODF, Open XML, plain text and HTML) and two more under "Other Acceptable Formats" (PDF and RTF).
The description and guidelines for the first two open formats, ODF 1.1 and Ecma 376 (Open XML), are nearly identical. Each is described as a "standardized XML-based file format specification suitable for office applications" that "covers the features required by text, spreadsheets, charts, and graphical documents." Each format also includes the following migration guidance: "All agencies are expected to migrate away from proprietary, binary office document formats to open, XML-based office document formats."
Where the descriptions of the two formats differ most is in the list of supporting applications. For ODF, the ETRM says "The OpenDocument format is currently supported by a variety of office applications including OpenOffice.org, StarOffice, KOffice, NeoOffice 2.1, and IBM Workplace. In addition, there are a number of translator software solutions that enable other office suites, such as Microsoft Office, to translate documents to and from OpenDocument Format for text documents. In the future, there will be translator software solutions for spreadsheets and presentations as well."
For Open XML, the ETRM says "The Open XML format is currently supported by a variety of office applications including Microsoft Office 2007, OpenOffice Novell Edition, and NeoOffice 2.1. Corel has announced Open XML support for WordPerfect 2007. In addition, the Microsoft Office Compatibility Pack enables older versions of Microsoft Office such as Office 2003, XP and 2000, to translate documents to and from Open XML Format for text, presentation and spreadsheet documents."
Continuing with the "Open Format" options, two other formats are recommended: plain text and HTML. For plain text, the ETRM notes that it "is the most portable format because it is supported by nearly every application on every machine," but it "should not be used for documents where formatting is important or is part of the official record." The ETRM describes HTML as "the preferred format for documents that will be accessed through the Internet/Intranet or using a web browser."
Rounding out the list is two non-open formats, PDF and RTF. PDF "may be used for documents whose content and structure will not undergo further modifications and need to be preserved," and RTF may be used "for ease of interoperability among different systems however XML-based document formats must be considered as a first choice."
Standards abertos para accessibilidade e Inclusão de todos os Cidadãos
Como requisito essencial de inclusão para documentos públicos implica adopção de standards que tenham incorporado essa funcionalidade como por exemplo o OASIS ODF 1.1 ou o ECMA Open XML. O standard ISO 26300 (ODF 1.0) nesta área não é adequado e apresenta limitações.
In the case of public documents that governments provide
to their nation’s citizens, it is also important that no
resident be excluded from data access. Public data should
be accessible to citizens independent of their income and
their physical abilities.
Accessibility in this case, has an entirely different meaning
for Persons with Disabilities (PwD). An open standard
dealing with document data must also be designed to enable
the addition of a range of assistive technologies such
that a person with no vision, or low vision, paralysis and
even severe motor skill limitations have sufficient access to
the software and document data to be able to author and
Aprovação ISO do ODF 1.2 em 2008 essencial para resolver os actuais problemas de interoperabilidade do actual ISO ODF 1.0
In May of 2006 an ISO Directive was issued insisting that ODF (ISO 26300) meet existing ISO Interoperability Requirements. The necessary changes to bring ODF 1.0, 1.1, and 1.2 into compliance with these ISO Interoperability Requirements has yet to occur.
We believe that if ODF 1.2 is brought into compliance with ISO Interoperability Requirements, much of the current interop mess will be resolved. Your application list will have to be re worked as the applications implement these requirements, but the public will finally have their expectations of ODF met.
Interoperabilidade é crucial para adopção do software livre pelos clientes
A interoperabilidade e standards abertos (ISO, de facto ou outros) estão no topo da agenda como o "FACTOR MAIS IMPORTANTE" na adopção com sucesso de soluções de software livre pelos clientes.
Ver estudo publicado este mês de Dezembro pela OSA:
... This is a very common interoperability requirement with customers (over 50% said they needed to make an open-source solution run on Windows or integrate with other Microsoft products such as IIS, ActiveDirectory or Sharepoint), and they are concerned that the industry is not doing enough to ensure such interoperability ....
... Open-source channel partners are also clamoring for interoperability. Many expressed that project durations were lengthened and margins reduced by making up for the lack of interoperability in many open source products. They prefer not to take on the headache themselves. As a result, they were more
likely to recommend solutions that exhibited superior modularity and interoperability ...
A existência e utilização de standards como ODF e OpenXML e guidelines de interoperabilidade facilita o trabalho de adopção para as soluções desenvolvidas pela comunidade de software livre, pois permite a grarantia de compatibilidade entre aplicações diferentes e nas aplicações de código aberto remove do cliente o custo/FUD de assegurar compatibilidade e interoperabildiade com outras aplicações de código aberto ou fechado que existam nos sistemas desse cliente, sendo que a compatibilidade é assegurada à priori pela compatibilidade com o standard ISO, adhoc, de facto, ou outro que seja utilizado pela indústria, num significativo conjunto de aplicações e entidades.
Clearly, interoperability is a key pain point for many customers. Most consider interoperability to be a “core feature” of any solution they adopt. Unfortunately many commercial open source ISVs have not developed their products this way, choosing to focus on the functionality of their respective point solutions before investing in interoperability with other solutions. This may make sense from a pure product development and release management perspective, but it results in customers not being able to adopt as quickly, hindering the vendors’ ability to drive revenue.
Customers don’t want a point solution. They need something that fits well into an end-to-end solution and the rest of their environment, and they make purchase decisions based on this. Consequently, vendors must treat interoperability as a core feature, and include it in “version one” of their respective products, instead of treating it as a future roadmap item. OASIS ODF 1.0 rings any bells ?
Esta é a estratégia correcta para a comunidade de software livre, a de procurar o mais possivel promover a interoperabilidade com a realidade existente nos clientes (muita dela Microsoft) através de processos de standardização e abertura dessa interfaces entre aplicações (ver exemplo do SAMBA), ao inves das absurdas campanhas e manipulação da comunidade contra standards e apostas fáceis de promover "rip and replace" mas impossiveis de implementar levadas a cabo pela SUN e IBM e que apenas a elas aproveita.
Senão vejamos a estratégia comercial que alguns destes fabricantes de alguma dimensão (e.g. SUN, IBM) têm seguido (e.g. ver caso da batalha pelo controlo dos formatos ODF e OpenXML nos posts deste blog), é totalmente absurda e prejudicial para toda a comunidade de software livre pois a SUN, IBM e seus parceiros, acham que esta questão da interoperabilidade é a sua principal diferenciação num cliente que quer adoptar software livre.
A razão é motivada pela pura ambição comercial pois a SUN e a IBM acham pela seu maior poder de lobi, dimensão ou reputação o cliente "confiará" ainda assim mais na sua capacidade de assegurar a compatibilidade e interoperabilidade (no fundo a manutenção e evolução), dando-lhes favoritismo e lock-in (first mover advantage) nesses clientes à partida num mundo onde predomina o FUD sobre interoperabilidade do software livre com os sistemas Microsoft actualmente utilizados pelo cliente.
Será esta a verdadeira razão porque a SUN se pode "dar ao luxo de fazer acordos de interoperabilidade com a Microsoft" ? Ou será que é por esta razão que um decisor público prefere escolher a SUN, IBM a uma solução nacional de software livre dado toda a contorvesia e todos os problemas de precepção criados pela SUN e IBM, ESOP ao redor das questões de interoperabilidade ? Apenas estas grandes multinacionais conseguem interoperar com a Microsoft porque é muito dificil para alguém de menor dimensão pois não existem standards abertos e gratuitos ?
Isto contraria frontalmente o espirito de colaboração e nivelamento de oportunidades e aumento das opções e concorrência que o modelo de desenvolvimento e colaboração do software livre permite. E torna claramente ilegal e pouco ético o favorecimento que ESOP procura obter para as suas associadas comerciais.
Também é muito fácil de perceber a distancia de aproximação a esta importante problemática por parte de algumas associações de empresas de software livre para promoção de soluções abertas como a OSA http://www.opensolutionsalliance.org/ e a nossa inqualificavel associação de lobi ESOP (que apenas se destina a fazer lobi a proveito de um cartel de amigos).
... with a few high-profile winners overshadowing a broad spectrum of underachievement. Fortunately, the differences between success and failure aren't insurmountable for most companies... Or, more frequently, the difference between success and an ongoing "zombie" state where companies keep hanging in there, barely earning enough to pay expenses.
Interoperability as an Afterthought
If only I had a nickel for every time I heard this: "I know I should make my product more interoperable, but I have to focus on my core features instead." Sounds good, but this misses the point that, increasingly, interoperability is a core feature.
Most commercial open source ISVs, especially application vendors, are small companies focusing on a point solution. But most customers don't want a point solution. They need something that fits well into an end-to-end solution and the rest of their environment. ISVs ignore this at their peril!
Successful ISVs go out of their way to plan for interoperability, starting in version 1, with modular and standards-based architectures. Moreover, they go out of their way to form an ecosystem of complementary ISV partners, and then collaboratively build out and test the integrations. This benefits them in two ways: First, it helps overcome interoperability as a sales objection, and second, they can pass leads and generate business for each other, all while making the customer happy.
Estudo OSA sobre os factores de adopção de software livre
Porque deve a comunidade de software livre não comercial suportar a standardização ISO do ECMA OpenXML ?
Why would Open Source developers want to support Open XML becoming an ISO standard? Isn’t it from Microsoft, the great Satan? Isn’t is some kind of trick or trap to stop nice Open Standard ODF? Are we going to let this chance to overthrow the monopoly escape?
First, I would like to set the scene. I think the reasons for supporting Open XML at ISO become a lot clearer if we take a fairly hard-headed view of what is possible. Which is perhaps a nicer way of saying that I think some of the anti-Open XML case has been built on naively faulty assumptions about the miraculous power of ODF to disrupt Microsoft.
No office suite or utility can afford to ignore any important format for long. So in a year’s time, every major office suite and utility (whether open source or not) will support ODF and Open XML, whether or not Open XML becomes an ISO standard.
No vendor will adopt, as their default save file format, a format which does not support their particular feature set. So the only way that MS would make ODF its default file format would be if (when) it is improved to support Office’s feature set. (Support for Office’s feature set was not a design goal or activity of ODF’s development. See the second item in the minutes of the first ODF meeting for example. Or see ODF’s Gary Edwards comment that “There is no possible way anyone can claim that today’s OASIS ODF TC would welcome Microsoft and make accommodating changes to the specification!”)
The poor state of ODF implementation by Open Source applications means that a too-fast adoption of ODF will backfire for Open Source developers. So paradoxically, supporting mandatory ODF too soon would be the kiss of death for open source ODF: bureaucrats will test applications and, finding them lacking, be forced to buy into a new generation of closed source tools (MS Office, IBM Lotus, Word Perfect, Sun Star Office.). If governments mandate ODF, it won’t exclude MS Office, in particular, and MS thinks their new GUI and features are competitive against other implementations, of course.
No matter what format you use, the only way to get 100% page fidelity (apart from some good-as-read-only format like PDF) is to save in the native save format and re-open the same file using exactly the same application on exactly the same operating system configured exactly the same. ODF won’t give instant interoperability in the sense of full page fidelity; I’d expect the same would be true of Open XML on different platforms too.
Putting it all together, it means that there was never a chance that Microsoft Office would or could adopt ISO ODF 1.0 as its native and default format. So the real choice that faces us is whether we want Office to generate files in a format that MS controls with very few external checks (with all respect to Ecma) or to generate files in a format that MS instigated but which has the extra checks and balances that come from being an ISO standard. ISO standardization is not an Aladdin’s cave of democratic rights, and it is not a Pandora’s box for Microsoft, but it is way better than nothing. Because that is what the anti-Open XML people would achieve: no controls on Microsoft. Under the guise of supporting ODF.
If you, like me, are in the position where you don’t use MS products in your normal work lives, then you may not feel any urgency to support Open XML, but I think we at least should not oppose it. It is a good step forward.
We often read that Microsoft is doing this as some kind of sinister ODF spoiler. However, Open XML is a path they have largely been forced to take (though obviously they will try to make the path as beneficial to them as possible) in order to fend off continuing anti-trust problems in Europe: Microsoft went down this path after a very strong hint from the European Union: in the same report that recommends that ODF be submitted to ISO, the EU’s ‘Telematics between Administrations Committee’ recommended that Microsoft should consider the merits of submitting XML formats to an international standards body of their choice as well as improving the documentation, IPR issues and going all the way with XML.
Vai a Microsoft retirar a proposta de standardização ISO do OpenXML caso os apoiantes da campanha anti-OpenXML sejam bem sucedidos ?
When critics ask to Microsoft "Why don't you use standards?" they will say "You can export from MSOffice to ODF via open source or SUN plug-ins, and we tried to make our formats a standard but we were rejected"...leaving them scott free to do anything they like.
The anti-Open XML people are guaranteeing that the political relationships between MS, the minority vendors, and the public remains the unchanged.
Um pouco de historia sobre um processo de standardização com os mesmos suspeitos do costume que me faz lembrar o processo actual do OpenXML com a ISO e ECMA ... e que realça o absurdo da actual campanha anti-OpenXML
Sun has withdrawn its application to make Java an ECMA standard. This is because Sun wants full control over the standard, and according to the procedures of ECMA, ECMA will themselves have full control over the standard (that is, the firms cooperating in ECMA, e.g., IBM, HP, Microsoft). Sun tried earlier to get Java accepted as an ISO standard; however, Sun withdrew that application too, because ISO also demanded full control over the process.
Vamos ter em Fevereiro 2008 uma repetição da História do ISO JAVA de ha 10 anos em que a SUN decidiu retirar a proposta a standard ISO depois de perceber que perder o controlo do desenvolvimento do JAVA não era do seu interesse ?
Capitulo 1 - A SUN submete o JAVA primeiro directamente ao ISO e depois atraves da ECMA um documento com +8000 páginas:
November 17, 1997
Sun Microsystems has won approval to submit its Java programming language to the International Standards Organization as a standard.
In a vote released today, 20 member nations in the ISO/IEC JTC 1 (the International Committee for Information Technology Standardization) approved Sun's application to become a "recognized submitter" of Java. The United States and China opposed Sun's application, two countries abstained, and three nations did not vote.
The vote is a key win in a long campaign for Sun, which now can control much of what goes into the Java standard. The company declined to say today when it would submit the specification, but JavaSoft vice president Jim Mitchell said the submission would take longer than three months because of its complexity.
Before the standard is submitted, JavaSoft must translate existing language into the ISO format. It also will circulate the specification among licensees and post it on its Web site. Once submitted to the standards body, the spec itself must be voted on and approved by ISO members.
Gaining status as an ISO standard would broaden Java's market because some government agencies and universities won't buy products unless they are based on ISO standards.
JavaSoft president Alan Baratz hailed the vote as a vindication of Sun's process for making Java an accepted standard, and he reaffirmed his company's intention to remain in charge of updates once ISO accepts Java as a standard.
"The Java platform will continue to evolve in exactly the same way it has as to this time, through a process we define," Baratz said. "We are not talking about the evolution of the Java platform being done by ISO or a compromise. The industry trusts Sun to do the right thing, and that's exactly what we're doing."
But analysts were mixed about the significance of today's announcement. "The industry needs a few alternatives to the Microsoft platform, and Java increases the likelihood of having those alternatives," said Jeff Kinz, research manager at IDC's Internet and application development group. "Even separate of that issue, Java's architecture is very useful. It provides a nice environment for deploying distributed applications."
But Larry Perlstein of Dataquest questioned whether having a Java standard will affect its adoption, noting that programming languages COBOL and C++ haven't achieved ISO standard status yet.
"Here are languages that have been around for ten years or more, and I don't know how much of a difference that has made," said Perlstein.
This is the second round of voting on whether Sun could submit Java in this manner. Sun altered its proposal after the first go-around to address objections raised to its original application. Still, 13 of the 20 votes to give Sun special "submitter" status came with comments or qualifications.
The U.S. delegation actually favored Sun's Java proposal by a vote of 15-10, but it didn't have the required two-thirds approval. The U.S. opposition came from Microsoft and others that objected to Sun controlling both the Java standard and the trademark as well as how the standard would evolve.
"We believe that if the comments are addressed, Java will be substantially more open than if the Sun proposal had gone through," said Cornelius Willis, a Microsoft spokesman. "This is one of the first steps in an involved process.
"Like many competitors and Sun allies, we think it would be a great thing if Java were a standard and we could participate in the evolution. Today we can't," he added.
JavaSoft's Baratz, defending Sun's strategy for making Java a standard, urged Microsoft to submit its technology to ISO to become a standard. "I would love for Microsoft to be half as open as Sun has been on Java."
Giving a single company submitter status is unusual for ISO.
Normally. such status is given to trade groups or consortia. Similar status has been given to X-Open, DAVIC (Digital Audio Visual Industry Council), VESA (Video Electronics Standards Association), and IrDA (Infrared Data Association).
But Sun has taken an unusual approach: It hopes to win International Standards Organization approval while maintaining ownership of Java.
Sun Microsystems Inc. lashed out at the Microsoft Corporation yesterday, saying that it would not give up its ownership of the Java computer language, as Microsoft and other companies have recently suggested, in order to have it officially certified as an international standard.
May 7, 1999
Sun Uses ECMA as Path to ISO Java Standardization
As expected, Sun Microsystems Inc will use ECMA as its route to the standardization of Java at ISO. In this way Sun hopes to be able to retain control over the future development of Java which it would have had to give up under new rules adopted by ISO's JTC1 committee and applied to the PAS process that Sun has now abandoned. ECMA standards can be fast-tracked to ISO standardization through a relationship ECMA has with ISO which Sun's VP Jim Mitchell described as "unique."
Whatever that means the fact is more than 100 ECMA standards have made it through to ISO standardization this way. Mitchell also claims there are no maintenance issues involved in this process and its ECMA submission leaves control of the specification in the hands of Sun's Java Community Process, the vehicle for extending the Java platform specifications. ECMA's only maintenance will be of a passive kind, fixing the wording of the spec itself. Sun's already submitted a Java 1.2.2 specification to ECMA which will be presented to a meeting of the group's general assembly in Kyoto, Japan on June 24. ECMA is expected to vote on the spec in December. Then it goes to ISO for fast track adoption.
Capitulo 2: A Sun retira a proposta da ECMA quando se apercebe que não poderá controlar sozinha o processo de desenvolvimento e a propriedade sobre o JAVA
Sun Microsystems Inc. has halted the Java International Standards Organization (ISO) standardization process.
During a recent meeting here with a technical committee formed by the European Computer Manufacturers Association (ECMA) standards body, Sun pulled specifications for Java, the Java Virtual Machine (JVM) and the Java API core class library off the table after copyright issues surfaced.
In April, Sun submitted Java to the ECMA to get on a fast track toward ISO approval.
ECMA's treatment of copyright issues is well-established, said ECMA secretary general Jan van den Beld, in reports. However, company lawyers learned at the meeting that ECMA doesn't have written copyright rules and that they needed more time to study the situation, a Sun spokeswoman said.
A subset of the technical committee, whose members include Sun rivals Hewlett-Packard Co. and Microsoft Corp., said the company has until next Wednesday to decide on one of three options.
Sun can either grant ECMA the right to use its copyrighted materials to craft its standard, let ECMA form standards on the basis of submissions from other committee members, or disband the committee and halt the process entirely.
Sun said the subset committee doesn't have the authority to impose such a deadline, and that it isn't binding. The spokeswoman said Sun's attorneys are working with van den Beld to come to an agreement.
Meanwhile, Java developers are mixed on the importance of ISO standards for Java.
Mikael Hansson, a consultant at Toronto-based FMC Software Consulting Inc., said ISO standards for Java would have more of a political value for Sun rather than a practical value for the developer community.
"Sun has made it clear that the Java development efforts will continue in the exact same way once under ISO, which means that this is more of an exercise in displaying a commitment to being open with the platform's future growth," Hansson said.
Standards help promote software reuse, which promotes rapid application development (RAD) and ensures that software is delivered bug-free, said Patrick Ryan, senior design engineer at Troy, Ohio-based Hobart Corp.
"But I must admit, in this case I'm a bit reserved," Ryan said. "I fear that if Sun turns over complete control of Java to a standards body, it will come under the influence of those who seek its demise."
Spokespeople from Santa Clara, Calif.-based Internet bill-management company CyberBills Inc. said ISO standards are important because too many entities still rely on them before officially adopting technology.
James Balliet, IT analyst at GraphOn Corp., Campbell, Calif., said standards make writing software easier for developers. "When you have standards, you have increased compatibility between products," he said.
In April, Sun submitted Java to the ECMA as a detour to ISO approval. Until then, the company relied on a different process, getting named as a publicly approved submitter (PAS) to the ISO.
Sun switched routes after a committee within the ISO rejected its efforts to retain control over Java's "maintenance," which consists of major updates to the technology.
The spokeswoman said Sun was a guinea pig in the PAS process and that the ECMA offered a faster and easier way to ISO standardization
Porque deve o ECMA Open XML ser tornado num standard ISO ?
uma visão de quem esteve 25 anos a fazer standards Jan van den Beld till April 2007 Secretary General of Ecma International.
A standard is not only a public document. A standard, certainly an IT standard is normally evolving over time. That evolvement is under public control and, so, its evolvement is public as well. That evolvement can happen under a hybrid construction such as OASIS and ISO/IEC for ODF, currently going on in OASIS already. In the near future we can expect a second Edition of ISO/IEC 26300 for ODF, if only to keep the evolving products compliant with the standard. Maybe we will see soon another interesting vetting process by the National Bodies interested in document formats.
A similar hybrid construction would be Ecma and ISO/IEC, for the evolution of OOXML.
A few years ago Ecma has tried to make an Ecma standard for Java, to be followed by a Fast Track into JTC 1, after SUN Microsystems had given up its own efforts to do this via the PAS procedure (such as used by OASIS for ODF). Why mention that Ecma effort on the standardization of Java, although that ultimately did not even start in Ecma? My main element of understanding why the project did not even start is that SUN did not want to go for public control: the Java specification turned into a public document, that was probably OK, but putting its further evolution under public control was a bridge too far, despite many efforts by Ecma members, in particular IBM.
But during that effort I had made a plan, in my role of SG of Ecma in those days. The plan consisted of getting on standardization paper all that was already in the Java specification, and all that WITHIN one year. That would have been a huge effort, turning the 8’500 Java spec pages into an Ecma standard. Writing a standard is an interesting challenge for engineers: transforming a product oriented spec into a set of requirements. The most dangerous moments are those when engineers say to each other ‘We know what we mean’.
After the ‘standardization year’ we would then go for FT. I have baptized that huge effort the ‘Catch up’ action. And during that year there would be hardly time for new functionality to go into the standard. My further thinking was that after a successful FT the evolution of the ISO/IEC standard for Java could really start.
When I had discussions with Microsoft about OOXML during the fourth quarter of 2005 I had exactly the same plan in mind as for Java. Today we are further with OOXML than we ever were for Java. And today it should be clear that, if the world wants the future evolution of the OOXML standard to happen under public control, then the NBs in ISO/IEC should successfully complete DIS 29500 i.e. complete the Catch up action for OOXML.
The first Edition of ISO/IEC 29500 is nothing more, and nothing less, than ‘the base for a new sculpture in standardization land’. In a technology-focused environment such as ISO/IEC this is an opportunity that should be carefully considered: that is the real responsibility of the NBs that make up the membership of ISO/IEC.
It is not only an opportunity for ISO/IEC to get the evolution of the OOXML standard under public control, but it will also bring a huge company like Microsoft to the standardization table. And another very important side effect of OOXML being an ISO/IEC standard will be that many more companies will implement new implementations such as, for example, particular spreadsheet programs because the specification is now public, and no longer in the private hands of Microsoft. The first developments in that direction are already becoming visible although OOXML is currently only an Ecma standard.
To get a product that is compliant with the standard there is no need to implement it completely. Also only those functions can be implemented that are considered to fit well for a particular application, opening up new commercial venues. In a product conformance statement one can list all the functions in the standard that the product supports. The OOXML standard specifies the possibilities for partial implementations in clause 2 of Part 1 of the standard: clause 2 in virtually every standard is the so-called Conformance clause. For example, in paragraph 2.6 in the Conformance clause the following is stated:
For the guidelines to be meaningful, a software application should be accompanied by publicly available documentation that describes what subset of this Standard it supports.
<a href="http://www.storyofstuff.com/">The Story of Stuff</a>
É a minha proposta de Ano Novo para ouvir e pensar.