Názor ke zprávičce Proč bude český hlas pro OOXML „ano“

1. Dokumenty typu strict a transitional - Microsoft může generovat všechny výstupy jako transitional a dohodnuté změny v klidu ignorovat.
Asi jste si neprostudoval dopad změn. Změny přijaté na BRM se týkají strict i transitional dokumentů. Všechny vlastnosti formátu, které jsou potřebné pro věrnou reprezentaci starých dokumentů, jsou nyní součástí pouze strict dokumentů. Co bude dělat MS a jiní implementátoři, je jejich věc. Mohou si vybrat, zda implementují podporu pro strict, transitional nebo obojí.

2. Lokalizované parametry se používaly již v binárních formátech - toto nás má přesvědčit, že mají být po převodu do OOXML, když je tak snadné je dopočítat pomocí vzorce? Asi vám unikl fakt, že onen lokalizovaný parametr nemusí být konstanta, ale výraz, který závisí na jiných buňkách a do těchto buněk může uživatel vkládat údaje, které ovlivní výsledek. Takže při konverzi z binárních formátů nejde tento případ vždy detekovat a nějak elegantně odstranit.

3. Práce s datem - povolené jsou obě varianty; proč se tenhle problém (jako jiné zmíněné) překládá na bedra ostatních?
Protože "chybná" varianta je použita v miliónech existujících dokumentů a nejde ji vždy automaticky detekovat (ze stejného případu jako v předchozím bodě).

4. Délkové jednotky - "je možné" používat i absolutní, takže chování bude předvídatelné. Děkujeme pěkně.
Asi jste si v původním dokumentu s připomínkami zapomněl přečíst důvod této připomínky. Cílem připomínky bylo umožnit použití "normálních" jednotek, pokud někdo generuje OOXML "ručně". Použití jednotek bylo v původní i opravené verzi OOXML zcela jednoznačné, nyní je navíc uživatelsky příjemnější pro ty, kdo budou OOXML generovat z různých aplikací (ručně to asi nikdo psát nebude ;-D).

5. Další rozhodnutí "v podstatě eliminovalo potřebu escapování" - takže eliminovalo, nebo ne?
Ve strict dokumentech escapování nebude potřeba. Navíc vám uniklo, že escapování je popsáno jednoznačně, akorát konkrétní stylistika věty může někdy vyznít ve smyslu, že se escapuje jen první podtžítko v celém řetězci a ne první podtržítko na začátku každé escape sekvence. To je detail, kterých jsou ve stávajících ISO normách tisíce, a snadno se vyjasní během následné údržby normy.

6. quickTimeFile je "v podstatě" synonymem videoFile - proč ho tam tedy nechali? Podle mého názoru se tohle ospravedlnit nedá.
Tak jsou v normě dva elementy, které jsou v podstatě synonyma. No a co. Proč je v HTML element <img> a <applet>, když obrázky i applety lze vkládat pomocí <object>?

7. "můžeme implementaci požadovat při první revizi normy" - to se tedy máte; pak vám třeba někdo vysvětlí, že implementace není možná a bude vymalováno.
Jaký vliv má na technický obsah normy to, zda se nějaká definici opakuje, nebo je uvedena jen jednou a vedou na ní odkazy? Žádný. Jaká má smysl na této změně trvat, když většina účastníků BRM měla opačný názor? Žádný.

8. Usnadnění přechodu na nové jazykové identifikátory - pokud jsou převoditelné jednoznačně, pak nechápu, proč tam ty "legacy" vůbec zůstaly. Pokud ne, jedná se o stejně závažný problém.
Protože "legacy" jazykové kódy mají jemnější členění než BCP-47 kódy, a někteří uživatelé chtějí tyto rozdíly zachovat při round-trippingu dokumentů. (Pokud se nepletu, nenabízí BCP-47 standardní způsob, jak rozlišit mezi tradiční a moderní španělštinou).

Problémy s roundtrippingem nejsou problém, který by měl standardizační komisi zajímat.
Divil byste se, pro kolik uživatelů je roundtripping důležitý (kvůli starým systémům, které umějí jen .doc a je zbytečné investovat do jejich upgrade). Standardizační komisi to musí setsakramentsky zajímat, když je to jeden z cílů normy.

Bohužel problematika dokumentových formátů, OOXML, potřeb uživatelů, kvanta existujících dokumentů atd. není tak jednoduchá, jak se na první pohled zdá. Bohužel mnoho lidí si neuvědomuje platnost jednoduchého motta - "Čím více toho vím, tím více vím, kolik toho nevím."