Buna ziua/seara domnule pianist... sa inceapa tragerile :) Presupun ca discutam despre specificatia pe care am gasit-o la adresa: http://www.ecma-international.org/publications/standards/Ecma-376.htm ( http://www.ecma-international.org/news/TC45_current_work/ )
In Office Open XML Part 4 - Markup Language Reference.pdf am gasit 'perla' asta (destul de 'faimoasa' de altfel) 2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing) This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 95) when determining the spacing between full-width East Asian characters in a document's content. [...snip...] Then applications should mimic the behavior of Microsoft Word 95 when determining the space between those characters, as needed. Iar in acelasi document, la o cautare sumara (CTRL+F) a cuprinsului (paginile numerotate de la 5 la 26) am mai gasit: 2.15.3.26 footnoteLayoutLikeWW8 (Emulate Word 6.x/95/97 Footnote Placement) 2.15.3.41 shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects) 2.15.3.63 useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules) Exista si alte probleme din aceasta categorie... cautati cuvantul "emulate" in acel cuprins. Oare ne va spune Microsoft EXACT CUM se calculeaza spatierea cuvintelor in Word sau asezarea in pagina? nu prea vad sa o faca fara sa fie nevoie sa semnezi un NDA daca incerci sa dezvolti un program care foloseste OOXML, iar obtinerea de acorduri la MS costa mult. Ce fel de standard liber si deschis se vrea a fi acesta cand trebuie sa 'cotizezi' la pusculita M$ daca vrei sa il implementezi corect ? D-le Dan, nu stiu daca cititi Groklaw, dar exact pe aceasta tema au fost publicate doua analize ale intalnirii recente din Portugalia: http://www.groklaw.net/article.php?story=20070720073215943 http://www.groklaw.net/article.php?story=2007071812280798 "Since ODF is underspecified, Microsoft would need to make proprietary extensions." Point blank. Perhaps you answer that translators can be written under NDA, but if that is the argument, then you are saying to me that Ecma-376 is really proprietary still, if the only way to interoperate is by means of NDA, and you are ensuring that 100% interoperability is impossible. Who will let us interoperate with the "proprietary extensions"? Can there be an open standard that must have proprietary extensions to work? And if Microsoft deliberately leaves ODF "underspecified" on purpose, what does that mean to you about Microsoft's interest in interoperability? What legal worries might we all have then? What about control issues? Wouldn't that provide Microsoft with every opportunity to control access and successful interoperability? They are free to do that, if they wish, but can you call that a standard? An open standard, to boot? Suplimentar, veti gasi ENORM de multe probleme cu OOXML prezentate pe http://www.grokdoc.net/index.php/EOOXML_objections Va rog sa le analizati cu atentie, nu stiu cum v-au scapat acestea la discutarea 'standardului' si votarea lui. Pe scurt mentionez (copy si paste de acolo, in lb. engleza deoarece sunt enorm de multe probleme si nu am timp sa le traduc): Ecma 376 section 3.17.4.1 page 3305, "Date Representation", conflicts with the Gregorian calendar in the calculation of dates. Specifically, it requires spreadsheet implementations to incorrectly treat the year 1900 as a leap year. This contradicts the Gregorian calendar, ISO 8601 and the civil calendar adopted by most nations of the world. Ecma 376 section 3.17.4.1 page 3305, "Date Representation" stipulates that dates must be represented as numeric codes counting from 1900 or 1904. This is in conflict with ISO 8601. This section also forbids applications from supporting years before 1900, also in conflict with ISO 8601. Ecma 376 section 2.18.52 page 2530, ST_LangCode requires the use of a fixed list of numeric language codes rather than the already existing set provided by ISO 639. This is a conflict with ISO 639. The codes standardized by ISO 639 include the use of a Registration Authority to process requests for new language codes. This is preferable to a fixed list attached to a document standard. Ecma 376 section 6.2.3.17 page 5679, "Embedded Object Alternate Image Requests Types" and section 6.4.3.1 page 5738, "Clipboard Format Types" refer to Windows Metafiles or Enhanced Metafiles instead of using ISO/IEC 8632 or W3C SVG. Ecma 376 duplicates the functionality of the existing OpenDocument standard as its core purpose is to support text documents, spreadsheets, drawings and presentations for office applications. Ecma 376 contradicts ISO 26300. Ecma 376 ignores accepted standards for cryptographic hashes and defies expert standards for cryptography, by proposing its own hash algorithms which are almost certainly flawed. * ISO has chosen the "Whirlpool" algorithm as standard ISO 10118-3. * The W3C, in its XML-ENC standard, includes a list of algorithms: SHA1, SHA256, SHA512, RIPEMD-160. * The European NESSIE project recommends: ISO 10118-3 ("Whirlpool"), SHA-256, SHA-384 and SHA-512. * In the USA, NIST recommends SHA1, SHA224, SHA256, SHA384, and SHA512. * In Japan, CRYPTREC recommends: MD5, RIPEMD-160, SHA1, SHA256, SHA384, and SHA512. Ecma 376 section 2.15.1.28 (page 1941) does not follow the advice of any of these organizations. Instead, it defines new hashing algorithms that have not undergone scrutiny by the cryptographic community. Fabricates units of measurement Many attributes throughout the Ecma 376 spec take values in "English Metric Units" (EMU). For example, attributes of type ST_PositiveCoordinate (5.1.12.42, page 4505) are measured in EMUs. This is not a known unit in existing literature. It is only defined inside a paragraph in section 5.9.2.1 page 655, so that "91440 EMUs/U.S. inch, 36000 EMUs/cm". Similarly, (2.18.105, page 1836 ) specifies "twips"—twentieths of a point (1/1440th of an inch) Ecma 376 section 2.18.46 (page 2521) contradicts the standard W3G SVG Color Keyword Names's hexadecimal RGB values for given color names. Undisclosed proprietary specifications Section 6.2.3.17 "Embedded Object Alternate Image Requests Types" (page 5679) requires implementors to support the proprietary Windows Metafiles. Cloning the behaviour of proprietary applications Several sections require the implementor to clone the behaviour of a proprietary product, where the behaviour to clone is not specified. For example: * Section 2.15.3.6 page 2161, autoSpaceLikeWord95. * Section 2.15.3.26 page 2199, footnoteLayoutLikeWW8. * Section 2.15.3.31 page 2209, lineWrapLikeWord6. * Section 2.15.3.32 page 2210, mwSmallCaps. * Section 2.15.3.41 page 2225, shapeLayoutLikeWW8. * Section 2.15.3.51 page 2245, suppressTopSpacingWP. * Section 2.15.3.53 page 2250, truncateFontHeightsLikeWP6. * Section 2.15.3.54 page 2252, uiCompat97To2003. * Section 2.15.3.63 page 2264, useWord2002TableStyleRules. * Section 2.15.3.64 page 2265, useWord97LineBreakRules. * Section 2.15.3.65 page 2266, wpJustification. * Section 2.15.3.66 page 2268, wpSpaceWidth. More can be found by searching Ecma 376 for the word "Guidance". si inca o TONA de probleme, nu are rost sa le mai includ aici. Adrian R. =========================================================== Pentru a renunta la abonament trimiteti un mail catre [EMAIL PROTECTED] incluzind in corpul mesajului: "unsubscribe tic-lobby <adresa_email>". Pagina web a listei se afla la http://beta.agora.ro/agora-bin/lwgate/TIC-LOBBY/ Arhiva se afla la http://beta.agora.ro/agora-bin/lwgate/tic-lobby/archives/
