Gepubliceerd: Dinsdag 15 januari 2008
De technische commissie voor Open XML van standaardenorganisatie ECMA heeft alle 3522 commentaren van de verschillende landen verwerkt.
Toon volledig artikel
Schikkeljaar? Oké
Ik ben benieuwd naar de volgende ronde, hoe loopt het met de stemvriendjes? Welke commentaren zijn naar wens veranderd? Zijn de stemmers blij dat er zo'n groot addendum is? Wachten ze op de EU onderzoeken?
Spannend, zal wel veel nieuwsberichten opleveren.
Zijn de stemmers blij dat er zo'n groot addendum is? Wachten ze op de EU onderzoeken
De stemmers zijn degenen die de reacties hadden gegeven waar deze aanpassingen op zijn gebaseerd.
De ISO leden hebben gedurende 2007 de specificatie kunnen reviewen en commentaren indienen en nu heeft Ecma dus de specificatie daarop aangepast en deze commentaren in de specificatie verwerkt.
Tijdens een komende Ballot Resolution Meeting in februari kunnen ISO leden de voorgestelde aanpassingen bediscussieren en beslissingen of deze inderdaad in de specificatie verwerkt moeten worden.
Na deze bijeenkomst kunnen de ISO leden nog een maand lang stemmen of de specificatie met de door henzelf goedgekeurde aanpassingen een internationale standaard moet worden. Er wordt dus niet gewacht op iets omdat het ISO proces gereguleerd wordt door de ISO directives.
Op zich is het gebruikelijk dat als een door een eerder tegenstemmend ISO lid ingediende bezwaren zijn verholpen dat deze dan voor de specifcatie stemt maar in dit bijzonderde geval is dat toch nog geen zekerheid omdat de motivatie voor veel van de tegenstemmen mogelijk helemaal niet bij de format specificatie zelf ligt en zij mogelijk tegenstemmen om politiek economische concurrentie redenen ook zonder dat zij nog openstaande bezwaren hebben uitstaan.
Er ook onoplosbare issues zoals Frankrijk die een issue heeft ingediend om de OOXML specificatie en de ODF specificatie samen te voegen. Een dergelijk verregaand voorstel is echter iets wat natuurlijk niet binnen het standaardisatieproces van OOXML kan worden opgelost als dat uberhaupt al mogelijk zou zijn. Aangezien de Fransen dat ook bij het indienen van dat commentaar wel konden bedenken is de vraag hoe zij daar mee omgaan. Ze hebben ook enkele honderden andere issues ingediend. Gebruiken zij een derglijke issue om aandacht te vragen voor samenwerking tussen OOXML en ODF of gebruiken zij een dergelijk issue om tegen te kunnen blijven stemmen ook als al de door hen ingediende tekstuele en technische issues mbt de formaat specificatie worden opgelost.
Al met al is de uiteindelijk uitkomst van de stemming nog onzeker.
Er waren in september 5 stemmen te kort van p-members voor een 2/3 meerderheid voor de standaard. Vrijwel zeker zullen nadat er nu heel veel issues zijn opgelost minder tegenstemmen zijn maar of die extra 5 stemmen van p-members worden gehaald is onduidelijk.
Baseline probeert vragen te beantwoorden die eerder suggestief zijn en waar de antwoorden door de gebruikers groot en klein beantwoord zullen worden.
ISO of niet, OOXML zal door gebruikers gebruikt moeten worden wil het de vraag kunnen overleven. De EU en grote(re) bedrijven lijken nu meer ODF te ondersteunen.
OOXML heeft een grote portemonnee achter zich, maar zal dit de doorslag geven?
Meer dan bij de vorige ronde zal de markt bepalen wat er gebruikt zal worden en daar zal gezicht verlies bij de gebruikende partijen misschien wel een rol spelen boven de vermeende kwaliteit winst.
Het is goed dat OOXML al aardig in de spotlight heeft gestaan. Los van ISO certificering wordt er tegenwoordig ook gekeken naar eventuele vendor-lockin en ingebouwde marktdominantie die met een formaat meekomen. Het is aan de EU om verzet te bieden aan Microsoft en geen gebruik te gaan maken van OOXML. Ikzelf stuur .docx bestanden standaard terug naar de afzender met het verzoek of ze het in ODF, RTF of desnoods .DOC willen zetten. Het is uiteindelijk aan ons om het succes van ODF te bepalen.
Het staat nu al vast dat Microsoft met OOXML opnieuw gaat proberen de markt over te nemen. Kijk maar naar HTML en Internet Explorer. Dat formaat wordt ondanks echte openheid al jaren door MS gegijzeld met rare functies en incompatibiliteit met de standaarden.
Filmpje om te verspreiden: http://www.youtube.com/watch?v=xCZ98bL1Y0U
Goede zaak. Eindelijk zal de de facto standaard een open standaard zijn en kan de door $un en IBM gecreërde strijd tussen Open en Closed (met als enig doel Microsoft aanvallen) beeindigd worden.
Ikzelf stuur ODF bestanden niet terug (erg flauw), maar converteer ze zelf naar OOXML.
Closed is MS Office 2007, closed is .doc (helaas), open is OOXML. Het programma mag voor mij closed, de informatiedrager bij voorkeur open.
Sun en IBM misbruiken een ideologische strijd om Microsoft dwars te zitten. Net zoiets als dat de USSR de Internationale misbruikte in hun strijd tegen de VSA. Idolaten van Open Source zijn niet meer dan pionnen in dit schaakspel.
Er zijn door de zeer grote aandacht die deze standaardfisatie heeft gekregen veel kleine fouten uitgehaald die er bijvoorbeeld bij ODF nog steeds in zitten omdat de ODF specificatie nauwelijks is bekeken.
Ook zijn er een aantal isses aangepakt die de specificatie interoperabiliteit verbeteren en zijn een aantal zaken flexibeler toe te passen zodat bijvoorbeeld niet westerse landen het formaat beter kunnen gebruiken.
Al met al een behoorlijk verbetering.
Bovendien is de specificatie van Office Open XML natuurlijk een stuk completer dan de specificatie van OpenDocument en daardoor al direct goed inzetbaar. Implementaties van opendocumetn zitten al ruim 2,5 jaar te wachten toch de specificatie wordt gecompleteerd waarna zij nog een conversie en implementatieslag zullen moeten maken van met name de redds gemaakte spreadsheets.
Het is dom om te veronderstellen dat een standaard geen fouten bevat. Het is evident dat ODf wat inderdaad al een standaard is nog honderden fouten bevat en ook nog lang niet voltooid is. Het lijkt daarom evident dat er voor Office Open XML heel andere kwaliteits criteria worden gehanteerd door bepaalde partijen dan voor ODf ooit het geval is geweest.
Als dezelfde kwaliteitsstandaarden ook bij ODF gehanteerd zouden zijn dan had ook de ODF specificatie honderden mutaties moeten ondergaan.
Ik zou wel willen weten waar dat gegeven vandaan komt?
Er zijn door de zeer grote aandacht die deze standaardfisatie heeft gekregen veel kleine fouten uitgehaald die er bijvoorbeeld bij ODF nog steeds in zitten omdat de ODF specificatie nauwelijks is bekeken.
ODF is bekeken en goedgekeurd, "nauwelijks" is denk ik een aanname. Waarom zou ODF minder streng bekeken zijn dan OOXML?
Het is de tactiek die Microsoft heeft gehanteerd en nog steeds probeert die me meer tegen de borst stuit. ODF is goedgekeurd zonder extra (omkoop) pogingen en MS is er niet doorgekomen met extra (omkoop) pogingen. Dit feit alleen al is meer waard dan een opmerking over nauwelijks bekeken. ODF en OOXML zullen nooit "klaar" zijn, bij vernieuwingen zullen ze beide mee moeten groeien. Die energie had MS beter aan ODF kunnen geven, maar nee hoor, ik grijp de strohalm en hefboom van mijn geld en macht en ga het toch proberen, daar licht OOXML, niet als wereld verbeterende standaard.
Of het wel of niet lukt staat haast niet meer tot de discussie, binnen Europa zal het eerder gezicht verlies zijn als overheden door de afgelopen en hangende zaken voor OOXML gaan kiezen.
Het MS imperium is tanende, niet alleen ODF vs OOXML, op echt alle fronten moet MS de zeilen bijzetten. Het wordt niet meer getolereerd dat MS verkeerde pressie uitvoert en wordt steeds meer gewezen op zijn verantwoordelijkheden.
Ik zou wel willen weten waar dat gegeven vandaan komt?
Hier is bijvoorbeeld een defects report van 12 december over ODF ingediend door de japanse ISO delegatie. Het bevat bijna honderd veelal simpele fouten in ODF maar sommige wel heel belangrijk bij interoperability (bijvoorbeeld afwijkingen tussen de normatieve tekst en de xml schema tekst). Let wel dat de Japanse delegatie voor de aanzienlijk uitgebreidere OOXML spec 82 bevindingen heeft ingediend. Daar zijn dan wel ook minder simpele issues bij maar dat er nu na zo lange tijd nog door een japanse vertaler die niet eens kijkt naar inhoudelijke correctheid zoveel fouten gevonden worden toont wel aan dat er bij de ODF spec maar heel vluchtig is gekeken naar de kwaliteit van de specificaties en meer naar het politieke belang van de standaardisatie.
De eerdere standaardisatie van ODF lijkt me dus in zoverre heel relevant dat we daaruit kunnen distilleren dat de kwaliteit van de Office Open XML specificatie eigenlijk niet zozeer de uiteindelijke stemming gaat bepalen omdat de kwaliteit of het gebrek aan volledigheid van ODF eerder blijkbaar ook al nauwelijks invloed heeft gehad op de standaardisdsatie van dat formaat.
Deze verbeteringsslag is wel belangrijk en goed voor het Office Open XML formaat maar hoe relevant het is voor de beslissing over standaardisatie is absoluut niet zeker. Het kan zijn dat deze aanzienlijke verbetringsinspanning voldoende is voor standaardisatie omdat er nog maar een paar stemmen nodig zijn voor de 2/3 meerderheid maar het kan ook zijn dat geen enkele verbetering voldoende zal zijn omdat er een andere bijvoorbeeld politieke motivatie zit achter deze ISO stemming.
Hier is bijvoorbeeld een defects report van 12 december over ODF ingediend door de japanse ISO delegatie
Ik heb dit al eens eerder gezegd: deze lijst bestaat voornamelijk uit onzin, dingen die aantoonbaar niet juist zijn, verzoeken om verduidelijking omdat ze de tekst niet snappen en correcties van tikfouten (die vaak ook niet juist zijn). Dus dat deze aanpassingen niet zijn meegenomen lijkt me niet meer dan terecht.
Baseline: jij weet hier volgens eigen zeggen meer van dan ik, dus ik stel voor dat jij die lijst pakt en de aantoonbare fouten waar je het over hebt eruit filtert en wat er overblijft ergens op internet gooit zodat iedereen z'n eigen oordeel kan vormen. Heb hem doorgebladerd en zag zo snel niet heel veel noemenswaardigs.
Dat doe ik als jij eerst even uit de 3522 reacties op Office Open XML even de ruim 3000 vergelijkbare kleine tekstuele wijzigingen of identieke issues even uitfiltert en de alleen de meer serieuze issues op een rijtje zet.
Het is niet zo dat de reacties op OOXML allemaal van een hoog niveau zijn:
Zo zitten er in de OOXML comments meer dan 100 commentaren waarin staat:
The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x.
Een kleine evidente fout in de beschrijving van enkele stastische formules maar wel ruim honderd gesubmitte vrijwel duplicate issues vaak zelfs inclusief de identiek gekopieerde schrijffout (means ipv mean).
Dat doe ik als jij eerst even uit de 3522 reacties op Office Open XML even de ruim 3000 vergelijkbare kleine tekstuele wijzigingen of identieke issues even uitfiltert en de alleen de meer serieuze issues op een rijtje zet.
Ik wil die uitdaging wel aan hoor. Heb je een linkje ernaar? (Jij hebt die vast bij de hand, ik heb geen zin ernaar te zoeken.)
Moet ik hieruit concluderen dat jij alle 2300 pagina's al grondig bestudeerd hebt of praat je gewoon het artikel na? 2300 pagina's is een flinke stapel papier en ik kan me niet voorstellen dat wanneer je bij pagina 1000 bent aangeland je nog weet wat je op 1 hebt gelezen. En die berg moet vóór eind februari zijn doorgeworsteld met de nodige aandacht?
Mocht het toch standaard worden, dan is op z'n minst de keiharde garantie van MS nodig, dat ze nadien niet alsnog weer afwijkingen van de standaard gaan inbouwen.
Het is aan de ISO leden om de oplossingen voor de door hen ingediende issues te beoordelen.
Gemiddeld hebben ze elk minder dan 100 issues ingebracht en dat lijkt me vrij eenvoudig te doen.
Overigens zijn de meeste antwoorden van Ecma ook bij duplicaten van elkaar omdat ook de meeste ingediende issues duplicaten van elkaar zijn. Het lijkt als totaal dus vooral veel meer dan het inhoudelijk werkelijk is.
Verder is volges de eerste commentaren van degenen die de issues hebben ingediend het grootste deel van de issues precies aangepast volgens wat er door de leden als oplossing was aangedragen
Uity het artikel ovedr de oude binarie bestandsformaten:
De mogelijkheden voor externe ontwikkelaars om met deze binaire bestandsformaten aan de slag te gaan zijn momenteel beperkt.
Dat is niet juist. Er zijn juist geen beperkingen voor externe ontwikkelaars om met deze binaire bestanden aan de slag te gaan. Microsoft geeft de specificaties daarvan op een zeer vrije licentie weg.
Echter het Micrsoft zal de formaten niet aan het publieke domain weggeven. Dat is zinloos omdat de enige toegevoegde waarde daarvan is dat de oude formaten dan juist weer verder kunnen aangepast/ontwikkeld/verbeterd en Microsoft wil natuurlijk juist dat deze formaten stabiel blijven terwijl er wordt ovegestapt naar de nieuwe XML gebaseerde office formaten.
Meneer Leenaars mag wel eens uitleggen wat hij of enigerlei externe ontwikkelaar van die binaire formaten nu niet niet zou mogen implementeren van deze formaten.
Ik vind je reactie belachtelijk en ongepast.
Als meneer Leenaars zich bij elke gelegenhied negetief wil uitlaten in de pers over bepaalde zaken zonder goede onbouwing dan moet hij verwachten dat dat kritiek oplevert. Hij heeft zichzelf in het artkel genoemd gekregen en dus zijn discussies over zijn uitspraken zelfs zeer on topic. Jou reacties daarop zijn zonder meer buitensporig
Het is toch niet meer dan logisch dat als ik vind dat hij hier opzettend een verkeerde voorstelling van zaken geeft in een artikel dat ik daar dan een opmerking over maak en een reacties op dat artikel.
Als er al haatgevoelens zijn dan zijn die vooral afkomstig van jou richting mij. Het is opvallend dat meer dan 90% van mijn reacties gevolgd worden door een reactie van jou waarin je over het algemeen mijn reacties aanvalt. Mischien moet je je eens focussen op de artikelen ipv op mijn commentaren.
Dat is zinloos omdat de enige toegevoegde waarde daarvan is dat de oude formaten dan juist weer verder kunnen aangepast/ontwikkeld/verbeterd en Microsoft wil natuurlijk juist dat deze formaten stabiel blijven terwijl er wordt ovegestapt naar de nieuwe XML gebaseerde office formaten.
Hallo! Sinds wanneer worden er publiek toegankelijke bestandsformaten op eigen houtje aangepast en uitgebreid? De enige die hier de zaak continu 'aanpaste/ontwikkelde/verbeterde' was Microsoft zelf, tot grote consternatie van alle gebruikers die zich genoodzaakt zagen tot bizarre conversietrucs omdat 'men' had besloten dat overzetten 'niet kon' (of, in een wat cynischer bui, 'niet mocht tenzij tegen forse betaling'). Recent flikte Microsoft het weer door botweg te weigeren hun eigen oude documenten in te lezen omdat die zogenaamd 'onveilig' zouden zijn.
Leenaars heeft natuurlijk volkomen gelijk. Langs deze weg blijft die legacy zooi bestaan, alleen nu onder de vlag van een ISO-standaard.
Het gaat helemaal niet om het implementeren van deze of gene functionaliteit. baseline beweerde dat MS de formaten niet open wilde gooien vanwege de vrees voor aanpassingen op eigen houtje---en dat is natuurlijk kul.
Dat bedoelde ik helemaal niet.
Ik heb het woord vrees niet in de mond genomen.
Het gaat erom dat Microsoft hun binaire formaten wil vervangen door nieuwe XML formaten.
Het is dan zinloos als een stabiele situatie willen behouden om de documenten aan een publieke organisatie in beheer te geven.
Microsoft stelt de binaire formaatspecificaties aan alle willekeuirge ontwikkelaars in de wereld ter beschikking voor implementatie waardoor er dus geen beperkingen zijn aan de implementatie zoals het artikel suggereert.
Een publieke organisatie kan de specificaties niet onder een vrijere licentie uitgeven dan Microsoft nu doet (omdat Microsoft dan ook nog steeds hun patenten moet licenseren) maar in theorie kan het formaat wel een door een publieke organisatie aangepast worden om de komende tien jaar dat het nog gebruikt zal worden bijvoorbeeld makkelijker op linux gebruikt te kunnen worden. Dat zou echter ongewenst zijn voor MS omdat zij geen nieuwe zaken in die oude binaire bestanden meer willen, maar die binaire bestanden gewoon aan de functionaliteit van MS Office gekoppeld willen houden. Vernieuwingen zullen dan moeten komen in interoperabele formaat Office Open XML, een formaat dat natuurlijk wel eenvoudig op allerlei configuraties kan worden gebruikt.
De leugens van Fjodor deel 1:
Microsoft wil dat je expliciet en schriftelijk toestemming vraagt en verkrijgt om de document-formaten te mogen gebruiken
Dat is onjuist.
Microsoft wil slechts dat je schriftelijk een licentieovereenkomst tekent. Ook voor bijvoorbeeld gebruik van open source is het heel normaal om akkoord te gaan met een bepaalde licentie. Dat beperkt ontwikkelaars niet in het gebruik van deze specificatie
De leugens van Fjodor deel 1:
daarnaast wordt toestemming alleen aan bedrijven verleend
Flauwekul.
Ook individuen kunnen door een getekende licentie op te sturen gratis de volledige formaatspecificatie toegestuurd krijgen.
het is in open source heel gebruikelijk om bestand-specifciaties over te geven, open source betekent openheid
Vreemd. Net was het volgens jou nog een voorwaarde vereist voor OSS implementatie nu is het aslechts gereduceerd tot iest wat gebruikelijk is maar blijkbaar geen vereiste voorwaarde meer.
Het is volslagen legitiem voor een OSS implementatie om gewoon de source code toe te voegen en voor de formaat specificatie te verwijzen naar Microsoft die deze format specificaties tenslotte gratis verstrekt.
Het is zelfs ook niet eens niet ongewoon dat door OSS software producten voor 3rd party formaten verwezen wordt naar de 3rd party als bron voor de formaatbeschijving.
Behalve dat je even een stuk of tien accountje hebt gebruikt om al mijn reacties weg te minnen en jezelf te plussen zie ik.
Ik vind het niet gek op jou van leugens te betichten.
We hebben deze discussie al meermaals gevoerd dus ik kan niet ander concluderen dat jij bepaalde interpretaties die onwaar zijn met opzet hier maakt.
Dat noem ik dus liegen !!!
Waar jij een berichtje schrijft met opzettelijk duidelijk aantoonbare en eenduidige onwaarheden (zoals dat alleen bedrijven de binaire specificaties kunnen aanvragen) en die dik in de plus zet maar de berichten die je ongelijk aantonen direct binnen een ppaar minuten flink mint is gewoon zielig.
Als er twintig minuten nadat ik een paar bwerichten heb gepost al mijn berichten op -6/6 tot - 8/8 gemodereerd zijn en alle berichten van Fjodor en KalePiet1 op +6/6 tot +8/8 dat weet ik wel hoe de vork in de steel zit.
Ik heb net even geteld dat op de laatste 80 threads met reacties die ik gegeven heb jij er op meer dan 70 met een negatieve reactie op die van mij hebt gereageerd. En dat nog gecombineerd met je voorliefde voor het wegmodereren van mijn reacties.
Je lijkt wel een gestoorde stalker man. Dat is pas waarlijk een obsessie.
Doe dus ff normaal en reageer gewoon niet op mijn berichten als je dat niet wilt.
Maar doe je dat wel dan zal ik gewoon reageren met dezelfde debiele methodes die jij toepast mafkees.
De leugens van Fjodor deel 3:
je hebt niet het recht om deze toestemming over te dragen, waardoor je de specificaties niet in open source kunt gebruiken
Flauwekul.
Je kunt de specificaties gewoon gebruiken voor het bouwen van een opensource implementatie. Je hoeft bij een OSs product namelijk de formaat specificatie namelijk helemaal niet over te dragen maar alleen de source code overdragen die op de specificatie is gebaseerd.
Voor de formaat specificatie geld dat deze is gemaakt door Microsoft en onder het auteursrecht valt van Microsoft en binnen de licentie maar voor de source code geldt dat deze gemaakt is door de OSS bouwer en onder zijn auteursrecht valt en dus zelf de licentie kan kiezen.
Dat zit elkaar dus volstrekt niet in de weg.
De semileugen van Fjodor deel 4:
Ook komt de toestemming te vervallen bij een bedrijfsovername of fusie
Dit is een overdreven interpretatie.Dat is lechts het geval als je daar niets aan doetn. De toestemming kan sowieso wel worden overgedragen met toestemming van Microsoft of (en dat is nog veel makkelijker) de licentie kan gewoon door het fusiebedrijf of overnemende bedrijf direct worden zelf aangevraagd door even de licentieovereenkomst op te sturen. Mits het fusiebedrijf natuurlijk geen patentconflict heeft met Microsoft over de betreffende binaire specificaties. Ofwel je kunt niet bij een patentconflict toch nog door een trucje licentierechten verwerven of verplaatsen door overdracht van deze rechten terwijl het toch aan een ieder vrij staat om de specificatie telkens opnieuw op te vragen bij Microsoft.
@ Fjodor
Dus helemaal niet open.
Het is meer open dan veel open licenties.
En ook nog gratis
Bovendien heb je het artikel nog niet gelezen denk ik.
Het gaat over beperkingen in het implemneteren van de formaten voor externe ontwikkelaars.
En die zijn er dus niet maar die probeer jij te verzinnen door onwaarheden te vertellen
Ach Albert, je blijft maar volharden in je openheid. Gezien de bovenstaande reeks reacties op het erop na houden van meerdere accounts, zie ik de temperatuur aardig oplopen zodat de stoom al uit de oren begint te spuiten.
Wind je niet zo op en sla daar op de baseline niet zo met de knuppel om je heen.
MS is uiteindelijk al die hartkloppingen van de opwinding niet waard.
Voor de liefhebbers van deze Office formaten problematiek.
De Burton Group heeft afgelopen week een gratis rapport gepubliceerd over de vernieuwing van de office formaten (wel eerst registreren)
Het rapport:
What’s Up, .DOC? ODF, OOXML, and the Revolutionary Implications of XML in Productivity Applications"
Het rapport is geschreven door Guy Creese and Peter O'Kelly
Grutjes, het wordt nu wel heel erg ingewikkeld allemaal. @WW-redactie: doe eens wat aan moderatie, al die mensen met dubbele accounts komen me m'n strot uit.
On-topic: ik wilde Albert/Baseline's uitdaging wel aan, ik wacht nog op een linkje naar een soortgelijk document als dat hij graag aanhaalt. Ik heb namelijk nog immer geen zin/tijd om er zelf naar te zoeken.
Lijkt me een zinloze bezigheid.
er is wel een site waar je de comments kan vinden
[url="http://www.dis29500.org/category/classification/dupe/"]DIS 29500 Comments[/quote]
en veel comment-nummers bevatten dezelfde gegevens
Dat komt omdat veel van de comments gewoon vrijwel identiek zijn.
Ik zie nu dat ik in de link de pagina met de classified duplicates had doorgegeven.
Vanaf de hoofdpagina www.dis29500.org kun je een wat meer diverse keuze maken uit de verschillende ingediende issues per land.
Mbt de duplicates.
Ipv van er 1 issue van te maken is er door verschillende ISO leden gekozen om dergelijke tekstuele issues per instance in de specificatie tekst in te dienen. Het had inderdaad nogal wat in aantallen issues gescheeld als men deze als 1 issue had ingediend dat betrekking had op meerdere statistische functies in de spec.
Dat ook verschillende ISO leden deze volstrekt identieke teksten gebruiken komt mede omdat een deel van deze issues zijn gekopieerd uit een document dat door IBM naar een groot aantal ISO national bodies is gestuurd. Met name de de inzendingen met grotere aantallen issues van bijvoorbeeld Chili, Colombia ,Frankrijk, Groot Brittanie en de VS bevatten daarom elke een zeer groot aantal zo goed als identieke duplicaten van elkaars issues.
Nee hoor dat zie je compleet verkeerd.
Er zijn op die site slechts 758 issues gekwalificeerd en daarvan zijn er 663 duplicates (en 42 stuks die dus die duplicaten hebben).
Dus ruim 80% van de gekwalificeerde issues is duplicate
en gemiddeld heeft een issue met duplicates rond de 16 duplicates
Er is geen andere site.
ISO had de comments per ongeluk kort gepubliceerd in hun document archief maar omdat de ISO directives verbieden dat de reacties van de ISO leden openbaar zijn zijn ze snel offline gehaald toen mensen daar heen begonnen te linken.
De bovenstaande site is opgezet door een tegenstander van OOXML die de de bestandjes snel gedownload had en in een wordpress site heeft ingelezen en ISO is daar dus ook niet echt blij mee.
De comments van de ISO leden en reacties van Ecma daarop worden door Ecma zelf ook wel gepubliceerd maar op een site die alleen toegankelijk is voor de ISO leden.
Daar is wel over geklaagd maar bijvoorbeeld de door ISO aangewezen organisator van de BRM heeft op zijn blog nog eens duidelijk aangegeven dat een keuze is van ISO en niet van Ecma.
Ik snap er nu helemaal niks meer van, maar dat kan ook komen omdat ik overwerkt en grieperig ben.
ISO had de comments per ongeluk kort gepubliceerd in hun document archief maar omdat de ISO directives verbieden dat de reacties van de ISO leden openbaar zijn zijn ze snel offline gehaald toen mensen daar heen begonnen te linken.
De comments zijn geheim? Waar hebben we het dan over? Hoe weet jij dan dat al die tig-comments duplicaten zijn van een masterlist van IBM? Ik neem dan toch aan dat je er zelf wel inzicht in hebt gehad, anders zou je dat niet kunnen stellen. En die Japanse comments op ODF, zijn die dan wel te vertrouwen? En waarom mochten die wel gepubliceerd worden?
En nee, ik ga inderdaad niet tussen de Woordperserrors zoeken naar informatie die wel of niet correct kan zijn. Als er een echte officiele lijst komt ooit zal ik die met liefde doorspitten, en ik zal hetzelfde doen voor een evt. lijst over ODF.
Maar niet dit vage gespeculeer over feiten die alleen ISO-leden worden geacht te kennen.
Dat is inderdaad een buitengewoon interessant document, Albert. Het ziet er vnl. naar uit alsof het onderdeel is van e.o.a. publieksactie tegen OOXML en niet zozeer het initiatief van IBM, maar dat terzijde.
Wat vooral interessant is zijn de genoemde bezwaren. Het zijn een kleine 8 pagina's met zeer legitieme redenen om OOXML niet tot standaard uit te roepen. (En geen 99 opmerkingen van een Japanner die niet goed Engels spreekt en daardoor allerlei onzinnige "fouten" denkt te vinden!)
Off-topic: kan iedereen in 's hemelsnaam gewoon onder 1 eigen uniek account gaan posten weer? Ik word echt driedubbel gestoord van modje[0-9]+ en aanverwanten...
Goed, om dus te resumeren:
- de bezwaren zijn in principe niet openbaar
- niemand heeft betrouwbare links naar originele documenten die door IBM zouden zijn gepushed
- niemand heeft uberhaupt zinvolle links naar zinvolle informatie
- <mening>OOXML is gewoon de zuig</mening>
Volgens mij zijn we wel uitgepraat dus. Er zijn verder geen argumenten omdat er geen bronnen zijn, behalve dan de specificaties zelf. En de specs van OOXML zijn de naam "standaard" volgens mij gewoon niet waard (nog). Maar goed, zo zijn ze ook nooit ontworpen volgens mij, dus dat verbaast me niet.
Komen jullie as vrijdag nog naar de "voeten op tafel sessie" bij Microsoft ?
http://blogs.microsoft.nl/ruud_de_jonge/archive/2007/12/23/eerste-voeten-op-tafel-sessie-bij-de-quot-leeuw-quot.aspx
Groeten,
Ruud de Jonge
Microsoft Nederland
Laat ik nou eens kijken waar ik naar toe zou moeten.
Op de MS-site staat een keurige routeplanner
Ik moet even invullen waar ik vandaan kom: Straatnaam, postcode, plaats.
Het lijkt mij voldoende om alleen de postcode in te vullen
Dat de postcode meteen een globaal vertrekpunt inhoud blijkt bij MS niet bekend want ik krijg een melding Geen locatie gevonden met het adres: , , , 1234 AA
Oke, ik geef nog een hint, de plaatsnaam erbij.
Melding: Meerdere resultaten gevonden, maak een keuze. Het vreemde is dat deze keuzemogelijkheden zich geen van allen in de door mij opgegeven plaats bevinden, maar wel met de plaatsnaam beginnen.
Goed, dan de straatnaam en plaats ingevuld. Jawel hoor, ik krijg keurig een routebeschrijving.
Maar, waarvoor is dan die postcode eigenlijk bedoeld???
Snap ik het nou niet of snappen ze het bij MS niet?
Ruud, je wilt die mensen toch wel echt ontvangen he? :-)
(natuurlijk in werkelijkheid correcte gegevens gebruikt)
Helaas kan ik dit soort dingen niet onder werktijd doen (en de maats van mijn linux-club ook niet). Als daar iets aan gedaan zou kunnen worden lijkt het me wel leuk om te praten. Altijd leuk om met andere IT'ers te bomen. Maar het heeft niet een dergelijke prioriteit dat de schaarse vrije dagen daaraan opgeofferd kunnen worden.
Overigens zou dat ook bij ons (nllgg) kunnen hoor. Wij houden regelmatig landelijke bijeenkomsten in Utrecht. Is wel op zaterdagen. De uitnodiging is overigens op persoonlijke titel. Dat moet ik er wel bij aangeven.
Er is helemaal geen behoefte aan een tweede 'standaard'. We hebben ook geen behoefte aan twee soorten gestandaardiseerde stopcontacten. Als Microsoft zou doen wat de klanten graag willen dat zou het gewoon ODF implementeren. Er zijn voor Microsoft geen technische of juridische belemmeringen om dat te doen.
Microsoft beschermt zijn monopolie met onder andere de MS-compatibiliteitsbarriere. Iedere vorm van standaardisering is een bedreiging voor Microsoft, aangezien standaardisering vrije concurrentie mogelijk zou maken. Economisch zijn er voor Micrsoft enorme prikkels om iedere vorm van standaardisering tegen te gaan. Iemand die denkt dat een commerciele instelling als Microsoft uit vrije wil over zou gaan tot een maatregel die haar eigen winst zou verkleinen noem ik buitengewoon naief.
Het streven van Microsoft om OOXML te standaardiseren moet niet gezien worden als een poging om de wereld te verrijken met een standaard maar juist om het standaardiseringsproces (een enorme bedreiging voor Microsoft) te frustreren.
Dat is dus het algemene verhaal, commerciele instellingen ondernemen niet uit vrije wil acties die goed zijn voor de wereld maar slecht voor haarzelf. Daarnaast is er nog de feitelijke situatie rond de standaard zelf.
Iemand merkte op dat er veel beter is gekeken naar OOXML dan naar ODF. Dat is niet juist. De voorbereiding van OOXML is niet openbaar geweest en heeft veel minder tijd gekost dan de voorbereiding van ODF. Vervolgens is OOXML via ECMA op een fast-track traject richting ISO gezet. Veel van de derde wereld landen die voor OOXML stemmen hebber er nooit naar gekeken, hebben zich exclusief bij de ISO aangemeld om voor OOXML te stemmen.
Aan alles is te zien dat ODF jarenlang - publiek - zorgvuldig is voorbereid door een consortium van spelers en dat OOXML er in no-time door een monopolist met veel geld doorgeduwd zal worden. De hoeveelheid fouten en vooral onduidelijkheden is astronomisch in OOXML. Daar komt nog bij de absurde lengte van OOXML. Hier zijn geen technische oorzaken voor. De lengte en vaagheid van OOXML hebben als bedoeling de implementatie hiervan zo ingewikkeld mogelijk te maken.
Als OOXML een ISO standaard is geworden zal er feitelijk ook niets veranderen. Microsoft is niet verplicht (en doet dat ook niet) om OOXML correct te implementeren in Office. Er zal een situatie komen waar er sprake is van ISO-OOXML (wat niemand gebruikt) en MS-OOXML (de standaard in Office). Microsoft controleert overigens dan zowel ISO-OOXML als MS-OOXML en kan de compatibiliteit breken, of juridische problemen creeren, waneer het wil. Eindgebruikers hebben in die situatie net zo min iets te zeggen over de bestandsformaten waarmee zij werken als nu. Waarschijnlijk zal Microsoft beloven dat de volgende versie van Office een werkelijk open standaard krijgt.
Om samen te vatten. OOXML is geen poging een standaard te creeren, het heeft als doelstelling de standaardisering van ODF te voorkomen. Waren de bedoeling van Microsoft richting standaardisering oprecht, kon het simpelweg ODF implementeren. Dit zou Microsoft minder kosten en een technisch superieur product opleveren. De ontwerpdoelstelling van ODF was een technisch goede standaard te creeren, de 'ontwerpdoelstelling' van OOXML was om een zo moeilijk mogelijk implementeerbare standaard te creeren.
Daar komt nog bij de absurde lengte van OOXML. Hier zijn geen technische oorzaken voor. De lengte en vaagheid van OOXML hebben als bedoeling de implementatie hiervan zo ingewikkeld mogelijk te maken.
Dat komt mede omdat ODF op basis van de specificatie niet implementeerbaar is.
Het barst in de ODF specificatie van de elementen waarvan volstrekt onduidelijk is wat ze doen of hoe je ze moet implemneteren. Dat staat namelijk gewoon niet in de specificatie.
Het is heel simpel om een korte specificatie te maken als je in de specificatie gewoon een serie tags neerpleurt en dan niet uitlegt hoe ze toegepast moeten worden of wat die formaat elementen in de specificatie eigenlijk zouden moeten doen.
Dat is in Office Open XML veel duidelijk beschreven en vaak met voorbeelden. Mede daarom is Office Open XML een veel grotere specificatie. Het enige wat je met de ODF specificatie kan bouwen is een systax en XML parser maar een office suite kun je er niet mee bouwen.
Verder is bijvoorbeeld de ODF specificatie beperkt qua functionaliteit. Zo beweren ze ondersteuning te bieden voor SVG maar dat is bijvoorbeeld onjuist omdat OpenDocument slechts een subsetje van SVG ondersteunt in een OpenOffice namespace en dus niet compatible is met SVG files.
Ook bijvoorbeeld de bij ISO ingediende PDF standaard is behoorlijk groter dan ODF terwijl PDF in essentie veel eenvoudiger is als presentatieformaat.
een standaard is geen implementatie-handleiding. Jammer dat je dat gezocht hebt.
Dat is dan wel weer gek want er zijn talloze tegenstanders van OOXML die aangeven dat Microsoft precies moet publiceren in hun standaard hoe alles werkt.
Maar bij de ODF standaard is het dus voldoende om te weten waaraan het formaat moet voldoen en niet hoe alles werkt. Weer die bijzondere dubbel standaard in het beoordelen van een formaat.
Maar probeer je nu nog steeds OOXML glans te geven door ODF af te kraken
Nee, ik probeer het astandaardisatie proces te vergelijken en zie hoe allerlei issues die tijdens de OOXML standaardisatie worden genoemd blijkbaar niet hoeven te gelden of op te gaan voor ODF.
er zijn talloze tegenstanders van OOXML die aangeven dat Microsoft precies moet publiceren in hun standaard hoe alles werkt
Er worden hier twee dingen door elkaar gehaald door Albert.
Een standaard hoeft niet aan te geven hoe je applicatie dient te werken. Zolang de applicatie iets uitpoept dat voldoet aan de standaard is dat prima.
Als de standaard, ik noem maar een voorbeeld, ergens roept "deze formules worden tussentijds opgeslagen in calcChain.xml om toekomstige acties te versnellen" en er staat vervolgens nergens hoe die calcChain.xml eruit moet zien (terwijl dat dus *wel* bij die standaard hoort, al vind ik dat zoiets niet in een standaard hoort maar dat terzijde) dan is dat fout.
OOXML moet het laatste doen maar doet dat op een aantal punten niet (NB: ik weet niet in hoeverre dat calcChain correct gespecificeerd staat in de specs, dit was een voorbeeld). Je kunt niet iets in een standaard opnemen (<parseLikeWord0.1>) en dan vervolgens niet uitleggen wat dat dan wel niet precies betekent. Dat bedoelen tegenstanders als ze zeggen dat die specificatie compleet moet zijn. Als je een voorbeeld van iets dergelijks uit ODF hebt hoor ik dat graag, inclusief betrouwbare bron.
Als de standaard, ik noem maar een voorbeeld, ergens roept "deze formules worden tussentijds opgeslagen in calcChain.xml om toekomstige acties te versnellen" en er staat vervolgens nergens hoe die calcChain.xml eruit moet zien (terwijl dat dus *wel* bij die standaard hoort, al vind ik dat zoiets niet in een standaard hoort maar dat terzijde) dan is dat fout.
Ten eerst zal ik maar even duidelijk vaststellen dat de calcchain volledig beschreven is in de specificatie en sla je er geen acties in op. Dat zou dubbel opslag zijn van wat er in spreadsheet cellen zit en dat is nou precies wat juist ODF weer wel doet.
Een calcchain is een methodiek om bij te houden in welke spreadsheet cellen formules zitten zodat je bij een mutatie in een spreadsheed alleen de calcchain moet doorrekenenen. Dat is een elementair en heel basis onderdeel van spreadsheet functionaliteit.
Wat ik echter bedoel is dat bij ODF echt elementen bestaan die je niet kunt implementeren zonder een aanvullende uitleg:
Bijvoorbeeld uit de ODF specificatie:
15.11.4 Vertical Glyph Orientation
The style:glyph-orientation-vertical property specifies the vertical glyph orientation. The property specifies an angle or automatic mode. The only possible angle is 0, which disables this feature.
<define name="style-table-cell-properties-attlist" combine="interleave">
<optional> <attribute name="style:glyph-orientation-vertical">
<choice>
<value>auto</value>
<value>0</value>
</choice> </attribute> </optional> </define>
Hoe moet je daar iets mee als je ODF wilt implementeren.
Ik heb meteen de volgende vragen:
* Wat is in ODF een glyph (er is geen ander element in ODF waarin het woord glyph voorkomt!)
* Wat is de vertical orientation. Is dat de orientatie ten opzicht van een as door het midden van de glyph ? Heeft zo'n ding wel een midden ?
* Waarom is de enige angle 0 (waarom zou je ooit dit element gebruiken als dat de enige angle is?)
* Wat betekent de waarde auto (of wat is automatic mode)
* Waarom ondersteunt dit element een combinatie van tekstuele en numerieke values ?
Het issue is dat de enige bestaande bron voor deze informatie de broncode is van OpenOffice. Dat is natuurlijk dramatisch voor een standaard.
en het stikt in de ODF spec van dat soort non-definities.
Ten eerst zal ik maar even duidelijk vaststellen dat de calcchain volledig beschreven is in de specificatie en sla je er geen acties in op. Dat zou dubbel opslag zijn van wat er in spreadsheet cellen zit en dat is nou precies wat juist ODF weer wel doet.
Het was dan ook een niet-bestaand voorbeeld, zoals ik al zei.
Hoe moet je daar iets mee als je ODF wilt implementeren.
Ik heb meteen de volgende vragen:
* Wat is in ODF een glyph (er is geen ander element in ODF waarin het woord glyph voorkomt!)
Een glyph is een karakter. Dus elk element in een bepaalde charset is een glyph. Dat is gewoon een Engels woord, en de ODF spec is geen woordenboek natuurlijk.
* Wat is de vertical orientation. Is dat de orientatie ten opzicht van een as door het midden van de glyph ? Heeft zo'n ding wel een midden ?
In dit kader is de vertical-orientation de richting waarin de tekst loopt (van boven naar beneden of van beneden naar boven of iets daar tussenin). Ook dit is een normale term en de uitleg hiervan hoort niet thuis in deze specs.
* Waarom is de enige angle 0 (waarom zou je ooit dit element gebruiken als dat de enige angle is?)
Omdat ODF kennelijk het overriden van de vertical-orientation van glyphs niet ondersteunt (je kunt dus in ODF geen Engels van rechts naar links schrijven, dat doe je maar in een tekenpakket dachten ze waarschijnlijk. Jammer voor Da Vinci).
* Wat betekent de waarde auto (of wat is automatic mode)
Zonder de betreffende passage uit m'n hoofd te kennen gok ik zomaar dat dat betekent dat je de standaardwaarde behorende bij whatever charset je mee bezig bent gebruikt.
* Waarom ondersteunt dit element een combinatie van tekstuele en numerieke values ?
Waarom niet? Naast een harde waarde kun je ook auto opgeven; vergelijk dit met CSS waar je naast waardes ook auto of inherit kun opgeven bij een property. Wat zou daar mis mee moeten zijn?
Als je de moeite had genomen nemen je te verdiepen in typografie (wel handig als je overweegt iets serieus met office-formaten te doen) en/of de Engelse taal snap je dat de uitleg van wat een glyph is en wat de orientation is niet thuishoort in de specificatie. Het feit dat je die moeite niet wilt nemen is de opstellers van de specs niet aan te rekenen. Maar ik snap nu je voorbeeld over die Japanse commentaren beter, die waren van hetzelfde niveau.
Overigens gaat horizontal en vertical orientation voor glyphs volgens mij ook in CSS3 zitten t.z.t., en zou die wel meer waardes dan 0 moeten gaan ondersteunen.
je kunt dus in ODF geen Engels van rechts naar links schrijven
Eh, iets te snel getypt. Dat zou natuurlijk met de horizontal orientation moeten :-) Vertical orientation is b.v. anders in het Japans (eerst boven naar beneden, dan links naar rechts ipv andersom zoals in de meeste Westerse talen).
Volgens mij moet ik weer eens met vakantie, want ik leg het zelf ook verkeerd uit. Maar ik ben dan ook geen expert :-) Voor de volledigheid:
Glyph-orientation heeft niks te maken met "Engels van rechts naar links" oid. Bij top-to-bottom (zoals in bepaald Aziatische talen) gebruik je vertical om de letters anders te "draaien". Is het left-to-right (of, presumably, right-to-left) dan gebruikt je horizontal voor hetzelfde doel (bijv. om al je karakters "achterover te laten hangen"). Maar dat laatste komt natuurlijk minder vaak voor.
Een mogelijke verhelderend voorbeeld (niet dat die in een tekstverwerker thuishoort, maar hij sluit wel mooi aan op het SVG verhaal elders in deze thread) is de rug van boeken. Wij doen dat top-to-bottom, en de default glyph-orientation-vertical is dan 90 (zodat je als het ware je hoofd een beetje naar rechts buigt om het te kunnen lezen). Wil je de letters echter echt
o
n
d
e
r
e
l
k
a
a
r
hebben, dan gebruik je waarde 0 (geen draaiing).
In Frankrijk en Duitsland gaat de tekst echter bottom-to-top op ruggen van boeken (je buigt je hoofd wat naar links). De default zal dan 270 zijn. Wil je dezelfde tekst nog enigszins leesbaar vergelijkbaar weergeven, dan zou je er dus 180 van moeten maken (niet voor te doen met HTML).
Echter, binnen de boeken is in beide gevallen de waarde 0, want je leest gewoon volgens de normale links-rechts, boven-benenden flow.
Ah, je weet er behoorlijk wat van.
Mooi. Voor mij duurde het wat langer want ik zocht het op in een dictionary en las toen dat glyphs grafische symbolen zijn zoals die bijvoorbeeld op stations en vliegvelden gebruikt worden.
Maar toen ik zoch naar vertical glyph orientation kwam ik terecht bij deze link
http://safari.oreilly.com/0596002238/svgess-CHP-8-SECT-6
Grappig genoeg zie je daar een voorbeeld van SVG (zou ODF ook al niet SVG compatible zijn?) en dan is 90 graden de default (ofwel een rotatie tov een vertikale as) en een angle van 0 graden is juist verticale tekst en dus zeker niet het uitschakelen van het element.
Zo logisch is wat jij zegt dus niet. De in ODF gekozen methodiek wijkt gewoon af van bijvoorbeeld de methodiek in een w3C standaard en het is dus raar dat het zo is gedefinieerd zonder verdere uitleg. Zo kun je het element niet niet meer gebruiken om een verticale tekst te creeren zoals in SVG omdat de waarde 0 een andere betekenis heeft. Verder zou het element volgens jou beschrijving nooit wat doen. Als de waard nul is is het disabled en als de waarde auto is dan is neemt het de normale orientatie over (wat naar ik aanneem ook hopelijk het gedrag is zonder dit style element)
Mooi. Voor mij duurde het wat langer want ik zocht het op in een dictionary en las toen dat glyphs grafische symbolen zijn zoals die bijvoorbeeld op stations en vliegvelden gebruikt worden.
Hmm... bijna correct: glyphs is de verzameling van alle iconen, pictogrammen, letters, cijfers, leestekens etc. die in een bepaalde charset zitten. Het is eigenlijk een universele naam voor "een menselijk symbool dat het een of ander voorstelt". Maar goed, da's muggenzifterij. 't Is in elk geval een volkomen normaal engels woord :-)
Maar toen ik zoch naar vertical glyph orientation kwam ik terecht bij deze link
http://safari.oreilly.com/0596002238/svgess-CHP-8-SECT-6
Grappig genoeg zie je daar een voorbeeld van SVG (zou ODF ook al niet SVG compatible zijn?) en dan is 90 graden de default (ofwel een rotatie tov een vertikale as) en een angle van 0 graden is juist verticale tekst en dus zeker niet het uitschakelen van het element.
Nee, je snapt dus nog niet precies waar het voor is. Als de tekstflow (in b.v. een engelse tekst) top-to-bottom is ipv left-to-right is de defaultwaarde 90 [graden]. Waarom? Omdat dan het hele woord draait, bij wijze van spreken - de tekstflow is top-to-bottom en elke letter is 90 graden gedraaid. Maar misschien wil je wel a la het uithangbord van een hotel het woord wel van boven naar beneden, maar de losse letters zelf wel volgens hun "normale" orientatie (dus niet "meegedraaid"). In dat geval kun je dat met deze property aanpassen. Het is dus geen property van een regel, maar van de karakters op een regel.
Kortom, ODF doet dat zoals andere standaarden het ook doen, zij het dat deze property in tekstdocumenten nauwelijks ondersteund is (en ook weinig te zoeken heeft IMHO).
Dit is weer typisch. Jij komt met de volgende stelling:
Wat ik echter bedoel is dat bij ODF echt elementen bestaan die je niet kunt implementeren zonder een aanvullende uitleg:
Als bewijs kom je met het verhaal dat er geen definitie staat in de standaard van de engels woorden "glyph" en "orientation". Iemand wijst er op dat dit duidelijk belachelijk is (hulde voor zijn geduld overigens).
Vervolgens ga je een enorme discussie aanzwengelen of het nou wel verstandig is dat de default waarde 0 of 90 graden is.
Dat is een red herring. Om de conclusie te ontlopen dat het ene onzin verhaal niet klopt, vlucht je in het andere onzin verhaal.
Vervolgens ga je een enorme discussie aanzwengelen of het nou wel verstandig is dat de default waarde 0 of 90 graden is.
Sterker nog, die redenatie klopte ook niet, en dat komt ook weer voort uit een onbegrip over de materie. Dat geeft niks, we kunnen niet allemaal experts zijn (nou ja, dat ben ik ook niet, ik lees misschien beter alleen), maar dhr. Albert heeft zich meerdere malen gepresenteerd als iemand die van de hoed en de rand weet, en valt hier opeens vreselijk door de mand.
Kennelijk kunnen we overigens ook concluderen dat OOXML glyph-orientation in het geheel niet ondersteunt, anders had Albert natuurlijk wel geweten was het was. /me gaat even Rob Weir mailen met nog een puntje voor de lijst... :-P
Ik weet het. Ik heb er het grootste respect voor dat je nog de moeite neemt om uit te leggen dat het niet klopte.
Ach, aanzien hoe iemand zichzelf kansloos de hoek in redeneert vind ik persoonlijk best vermakelijk, hoor ;-)
Aja dat is ook wel geinig. Volgens mij begon het hier mee:
Je kunt niet iets in een standaard opnemen (<parseLikeWord0.1>) en dan vervolgens niet uitleggen wat dat dan wel niet precies betekent. Dat bedoelen tegenstanders als ze zeggen dat die specificatie compleet moet zijn. Als je een voorbeeld van iets dergelijks uit ODF hebt hoor ik dat graag, inclusief betrouwbare bron.
Met dat voorbeeld in ODF op te proppen lukte dus niet. Maar ondertussen is iedereen wel vergeten dat het er mee begon dat we het juist over voorbeelden in OOXML hadden waar de standaard niet volledig was. Dus als dat de opzet was, en dat vermoeden heb ik, is Baseline daar toch wel aardig in geslaagd.
Je laat natuurlijk even achterwege de punten
* dat 0 in ODF het uitschakelen van de feature is terwijl het in SVG een geldige angle is.
* en je laat achterwege wat de value auto nou eigenlijk doet maar gokt slechts een mogelijke oplossing wat het zou kunnen betekenen maar wel een oplossingen waardoor het erop lijkt dat de glyph orientation een feature is die in ODF helemaal niets doet.
Zucht... ik ben ook eigenlijk te goed voor deze wereld en verkas zo naar het nieuwste topic hierover waar het ongetwijfeld ook weer erg gezellig is, maar voor de volledigheid (als je op glyph-orientation-vertical googlet krijg je vnl. webwereld-posts waar Baseline dat aanvoert als fout in ODF, en dat is niet goed):
Je laat natuurlijk even achterwege de punten
* dat 0 in ODF het uitschakelen van de feature is terwijl het in SVG een geldige angle is.
* en je laat achterwege wat de value auto nou eigenlijk doet maar gokt slechts een mogelijke oplossing wat het zou kunnen betekenen maar wel een oplossingen waardoor het erop lijkt dat de glyph orientation een feature is die in ODF helemaal niets doet.
Gast, leer nou eens begrijpend lezen. 0 is de enige toegestane waarde omdat het niet de bedoeling is dat je je tekstverwerker als DTP-pakket gebruikt. Daar heb je - oh shock! - DTP-pakketten voor.
Wat automatic mode is heb ik je ook al uitgelegd, namelijk overnemen wat bij de text-orientation hoort voor de gebruikte charset.
Dus nee, glyph-orientation doet heel weinig in ODF op het moment. Maar als ze ooit een DTP pakket maken dat ook met ODF werkt kan dat dus uitgebreid worden. Hou nou toch alsjeblieft op met ODF de schuld te geven van je eigen gebrek aan kennis op dit gebied.
Ik moet begrijpend lezen maar je bevestigd wel precies dat wat ik zeg ?
ODF bevat een feature die niets doet omdat "er mogelijk in de toekomst een pakket dat ODF gebruikt komt en ze dat deze feature kunnen uitbreiden".
Vervelend dan alleen dat ze met die toekomst in gedacht dan geen value "off" hebben gedefinieerd maar de angle value 0 hebben misbruikt om de feature uit te zetten. Uberhaupt waarom een feature opnemen die niets doet maar als je de feature wilt gebruiken eerst qua functionaliteit in de standaard moet worden uitgebreid. Dan zou je net zo goed hebben kunnen wachten met deze nutteloze feature toevoegen tot dat moment daar is.
En je conclusie dat glyph orientatie alleen voor DTP pakketten is voor je eigen rekening.
Ik neem aan dat je dat iets degelijks vind voor elke feature die door ODF niet ondersteund word.
Vervelend dan alleen dat ze met die toekomst in gedacht dan geen value "off" hebben gedefinieerd maar de angle value 0 hebben misbruikt om de feature uit te zetten.
Als je b.v. naar CSS kijkt: daar werkt dat ook zo. Niemand gebruikt "off" want dat impliceert dat je ook "on" hebt (een soort boolean dus). "0" wil zeggen "letter rechtop", "auto" wil zeggen "letter gedraaid volgens de regel waar hij in staat". Andere waardes zijn niet mogelijk omdat dat in een tekstverwerker nergens op zou slaan.
Uberhaupt waarom een feature opnemen die niets doet maar als je de feature wilt gebruiken eerst qua functionaliteit in de standaard moet worden uitgebreid. Dan zou je net zo goed hebben kunnen wachten met deze nutteloze feature toevoegen tot dat moment daar is.
De feature is niet nutteloos, hij is alleen maar in zeer beperkte mate aanwezig in de bestandsformaten waar het in deze context om gaat.
En je conclusie dat glyph orientatie alleen voor DTP pakketten is voor je eigen rekening.
Ik neem aan dat je dat iets degelijks vind voor elke feature die door ODF niet ondersteund word.
Oh, dat zou zomaar kunnen. Ik ga ervan uit dat voor veel dingen best goede redenen zijn geweest. Lijkt me niet zo'n vreemde aanname bij een ISO-standaard, hoor.
Waren de bedoeling van Microsoft richting standaardisering oprecht, kon het simpelweg ODF implementeren. Dit zou Microsoft minder kosten en een technisch superieur product opleveren.
Wat een onzin. Dat zou helemaal niet simpelweg kunnen.
* ODF bevat stapels minder functionaliteit dan OOXML
* Beiden gebruiken een totaal verschillend document concept (mixed model vs non-mixed model)
* De ontbrekende spreadsheet functionaliteit in ODF is in OOXML al meer pagina's dan de hele ODF standaard groot is.
* ODF is niet technisch superieur maar inferieur omdat het zeer ernstige beperkingen heeft door een vreemde combinatie van bijelkaar geplakte web standaard onderdelen.
* Zo kun je bijvoorbeeld in bepaalde delen van ODF geen revisies bijhouden omdat de schema's geplukt zijn uit een webstandaard waarin je helemaal geen office functionaliteit ondersteunt en dus oook geen revisie elementen hebt. Juist in bijvoorbeeld Office Open XML waarin alle delen zijn ontworpen om te functioneren in een Office document applicatie kun je dus wel dergelijke belangrijke office functionaliteit door de gehele specificatie heen toepassen.
* OOXML is bijvoorbeeld ontworpen om met zeer grote spreadsheets te kunnen werken en bied functionliteit voor betere performance in dergelijk spreadsheets ODF biedt dergelijk functionaliteit niet
* Voor Microsoft zou, door ODF toe te passen, dus de functionaliteit van MS Office duidelijk worden verminderd en aangetast en ook nog trager worden en moeilijk grotere spreadhseets aankunnen. Dat is niet superieur maar inferieur.
Baseline,
Jij pikt twee bijzinnen uit mijn stukje en maakt daar een hoop kabaal over. De argumenten die je inbrengt zijn niet in overeenstemming met de feiten of zelfs strijdig met de logica op zichzelf. Schrijnend is het dan wel dat je wat betreft de hoofdlijnen van mijn verhaal nog niet eens in staat blijkt om er incorrecte of onlogische argumenten tegen in te brengen.
Jij doet een poging om een logisch en consistent verhaal (waarvan je waarschijnlijk zelf ook wel weet dat het correct is) te bedelven onder een hoop irrelevante, onlogische, ongefundeerde en inconsistente opmerkingen die betrekking hebben op _bijzaken_ in de hoop dat mensen de _hoofdlijn_ van het verhaal kwijtraken.
Maar er is nog veel meer zelf verzonnen onzin in jou eerdere reactie
Ik zal gewoon nog eens ingaan op wat jij als intro noemt
Als Microsoft zou doen wat de klanten graag willen dat zou het gewoon ODF implementeren
Dat is pas pure zelfverzonnen flauwekul.
De enigen die dat willen zijn een paar anti-ms of oss fanboys.
Klanten willen betrouwbaarheid, stabiliteit en continuiteit en ODF biedt dat absoluut niet.
En ODF's grootste selling point is interoperabiliteit en ook dat is nog lang niet goed gerealiseerd want interoperabiliteit tussen ODF implementaties if nog van een aanzienlijk lager niveau dan die van bijvoorbeeld de binaire .doc formaten.
Juist de klanten van Micrsoft eisen een in hoge mate compatible formaat dat ee eenvoudige en 100% betrouwbare conversie garandeert. Juist de klanten van Micrsoft willen Office Open XML. Ik zit bijvoorbeeld in zo'n klantorganisatie en daar gaan we zeker niet over op ODf zolang daar geen betrouwbare spreadsheet formaule's inzitten waarvan we weten dat er een betrouwbare imp,ementatie is
Als er iemand komt met redherrings ben jij dat wel.
Het gaat hier over de standaardisatie proces van OOXML en als argument kom jij met een volledig uit de lucht gegrepen zelf verzonnen en onbewezen stelling dat klanten van Micrsoft ODF zouden willen.
Verder die je nog veel meer beweringen die gewoon uit eigen pen komen en volstrekt niet op enigerlei aantoonbare feiten steunen. Je doet zelfs een hele reeks van negatieve veronderstellingen over wat Microsoft in de toekomst wel of niet zal gaan doen en presenteert ze als een absolute waarheid.
Bovendien zijn die dubieuze toekomstvoorspellingen over Micrsoft en OOXML dan ook nog heel onhandige argumenten want dezelfde argumenten gaan ook op voor Microsoft en ODF en dan kun je daruit alleen maar concluderen dqat je ook niet wilt dat Microsoft ODF gaant ondersteunen maar gewoon een globale anti-Microsoft houding presenteert als tegenargument tegen Office Open XML .
Vooruit, nog een poging wat zinnigheid te verspreiden.
Als er iemand komt met redherrings ben jij dat wel.
http://www.fallacyfiles.org/tuquoque.html
Het gaat hier over de standaardisatie proces van OOXML en als argument kom jij met een volledig uit de lucht gegrepen zelf verzonnen en onbewezen stelling dat klanten van Micrsoft ODF zouden willen.
Dit is altijd hetzelfde liedje. Klanten vragen om iets, Microsoft geeft als antwoord dat doen we niet want onze klanten willen het niet.
De lijst met instanties, bedrijven en thuisgebruikers die om native ODF support (of support van andere open standaarden) hebben gevraagd is enorm.
Lees bijvoorbeeld het recente Becta rapport eens. Zij vragen al geruime tijd om native ODF support van Microsoft.
Werkelijk, met Google had je eenvoudig kunnen weerleggen dat deze stelling niet "volledig uit de lucht gegrepen zelf verzonnen en onbewezen" is.
Verder die je nog veel meer beweringen die gewoon uit eigen pen komen en volstrekt niet op enigerlei aantoonbare feiten steunen. Je doet zelfs een hele reeks van negatieve veronderstellingen over wat Microsoft in de toekomst wel of niet zal gaan doen en presenteert ze als een absolute waarheid.
Ik baseer die veronderstellingen op twee zaken. Ten eerste het gedrag van Microsoft in het verleden. Ten tweede de assumptie dat Microsoft, zoals iedere commerciele instelling, zoveel mogelijk winst wil maken.
Om zoveel mogelijk winst te maken moet het monopolie in stand blijven. Om het monopolie in stand te houden moet Microsoft open standaarden bestrijden. Inderdaad, zoals het in het verleden ook al altijd open standaarden heeft bestreden.
Bovendien zijn die dubieuze toekomstvoorspellingen over Micrsoft en OOXML dan ook nog heel onhandige argumenten want dezelfde argumenten gaan ook op voor Microsoft en ODF
Gedeeltelijk. Microsoft zal nooit uit vrije wel een echt open standaard ondersteunen. Open standaarden maken namelijk vrije concurrentie mogelijk en vormen dus een bedreiging voor het monopolie en dus de winstgevendheid van Microsoft.
Een belangrijk verschil is dat Microsoft niet de ODF standaard kan controleren zoals het dat met wel met OOXML kan doen. Daarnaast is OOXML technisch inferieur.
en dan kun je daruit alleen maar concluderen dqat je ook niet wilt dat Microsoft ODF gaant ondersteunen maar gewoon een globale anti-Microsoft houding presenteert als tegenargument tegen Office Open XML .
Zowel de stelling dat je daar maar 1 conclusie uit kunt trekken als de conclusie zelf zijn niet correct.
Ik wil wel dat Microsoft ODF gaat ondersteunen, maar op een hele specifieke manier. Ik wil namelijk dat Microsoft ODF op een correcte manier gaat ondersteunen. Om de redenen die ik al heb aangegeven zal Microsoft dit nooit uit vrije wil doen. Daarom is hiervoor ofwel wetgeving nodig, ofwel zullen consumenten correcte implementatie moeten afdwingen.
Speciaal voor Theodoor (en aliasses) heb ik nog even aan mijn 'vrienden' van Microsoft gevraagd om de binaire specificaties ook met downloadje beschikbaar te stellen omdat hij het zo moeilijk vind om ze bij Microsoft aan te vragen.
En zie hier:
blogs.msdn.com/...xml-format.aspx
Ik denk dat je het artikel gewoon niet leest of zo.
Microsoft will also make the Binary Formats subject to its Open Specification Promise (see www.microsoft.com/interop/osp) by February 15, 2008.
Het leek mij ook een vrij normale opmerking, maar goed. Op zichzelf is het nieteens iets wat perse tegen Microsoft gericht is. Blijkbaar heb ik in andere posts dingen aangekaart die niet langs te censuur kunnen en zijn nu alle posts van mij verdacht.
Dat was denk ik een cynische opmerking van Fjodor omdat Fjodor in de reactie waar je op reageerde al had neergezet dat de datum relevant is.
Dat jij dezelfde fout nog een keer maakt nadat het met nadruk herhaald werd is een beetje lachwekkend.
Make it even easier to get access to the Binary Formats documentation by posting it and making it available for a direct download on the Microsoft web site no later than February 15, 2008. The Binary Formats have been under a covenant not to sue and Microsoft will also make them available under its Open Specification Promise (see www.microsoft.com/interop/osp) by the time they are posted.
Als ik vervolgens op www.microsoft.com/interop/osp kijk zie ik geen MS-Office binary file formats staan. Daar is volgens mij niets 'lachwekkend' aan.
Zonder dit moderatie systeem is het al moeilijk genoeg om een redelijke discussie te voeren.
Overigens denk ik wel dat webwereld hier voordeel bij heeft. Als er mensen zijn die enorm vaak gaan inloggen om te 'modereren' verkopen ze weer extra advertenties. Of is dat vergezocht?
Dat hele moderatiesysteem klopt ook van geen kanten, maar dat heb ik al vaker uitgelegd. Wat je wilt is dat iemand nadenkt voor-ie + of - uitdeelt. Dat kan dus alleen als het uitdelen van zoiets op de een of andere manier "duur" is, of geen zin heeft als dat je enige bezigheid is.
Voorbeeld: iemand die veel berichten plaatst welke goed gewaardeerd worden deelt een minnetje uit aan een trol (die als-ie al berichten plaatst slecht gewaardeerd zal worden). Deze min telt heel zwaar.
Andersom is er voor een trol de lol snel vanaf als al zijn minnetjes niet of nauwelijks tellen omdat er nooit een bericht van hem (of haar) positief is beoordeeld. Zolang niet een meederheid van je leden uit zichzelf omhoog plussende trollen bestaat gaat het dan al een stuk beter.
Dan ga je ervan uit dat iemand die weinig berichten plaatst minder verstandig modereert dan iemand die veel berichten plaatst, en dat is ook verkeerd.
Nee, sorry, dat bedoelde ik niet. De formulering was inderdaad wat ambigu. Ik bedoelde iemand wiens berichten vaker positief dan negatief worden gewaardeerd. Het absolute aantal mag ook wel iets meespelen, maar minder zwaar.
Maar wel een beetje, want iemand die zelf actief is heeft in een community meer waarde dan iemand die alleen maar vanaf de zijlijn commentaar levert. Ik denk dat zelf posten wel sowieso een gewicht moet hebben in stemmen.
Theodoor, vind je het niet een beetje flauw om Albert aan te vallen op iets waar je zelf in het verleden en nu nog steeds eveneens gebruik van maakt? Zo is HandigeHarry ineens vrijwel van het toneel verdwenen, evenals Kalepiet1 en is Fjodor daarvoor in de plaats gekomen. Toen jullie nog "netjes" accounts NA elkaar gebruikten was het nog te volgen, maar nu jullie ze door elkaar heen gebruiken wordt het wat onoverzichtelijk.
En dat allemaal door die beoordelingen...
Laten we zeggen dat ik het aan Fjodor richtte, die qua schrijfwijze vreselijk veel lijkt op KalePiet1, HandigeHarry, Regisalbert, Theodoor, KleineWilliam, Smallbill, Hectometerpaaltje en incidenteel Flebflab, Flebflab2 en Bugmenot2007.
Mijn kritiek gold eveneens voor Albert, Regis, Baseline, Zap, Zapato en een aantal Mod-jes.
Mocht ik hier onzin uitkramen, dan excuses hiervoor, maar ik zie door de nicknames onderhand het bos ook niet meer.
@edjez: volgens mij heb je het 100% bij het rechte eind.
Alsnog een goed voornemen voor 2008: iedereen stopt met kinderachtig doen en gaat gewoon 1 en dezelfde nick gebruiken. Dit is (wat mij betreft, allicht tegen beter weten in) een plek waar slimme mensen op een verstandige manier discussie proberen te voeren over onderwerpen die ons allen aangaan.
Laat ons deze discussie op volwassen wijze en met open vizier voeren.
Ik heb er binnen een minuut de volgende tekst voor geformuleerd:
Ik wens niet op deze poster te reageren. Deze poster gebruikt meerdere accounts, of meerdere posters maken gebruik van een en hetzelfde account. Dit komt de discussie niet ten goede.
Bovenstaande staat los van mijn feitelijke mening over bedoelde post. Ik kan het ermee eens zijn of niet, maar op deze manier heeft reageren weinig zin.
Happy copy/pasting! :-)
Zou het niet beter zijn dit soort discussies te voeren op een forum waar het niet mogelijk is voor 1 iemand om de hele discussie te verstieren door iedereen die het niet met hem eens is zoveel mogelijk minnen te geven?
Zou het niet beter zijn dit soort discussies te voeren op een forum waar het niet mogelijk is voor 1 iemand om de hele discussie te verstieren door iedereen die het niet met hem eens is zoveel mogelijk minnen te geven?
Goed idee, we verkassen met z'n allen naar Slashdot?
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
