Gepubliceerd: Woensdag 6 februari 2008
In het debat rond de open standaarden heeft IBM concurrent Microsoft stevig van repliek gediend: het Office Open XML-formaat zou "technisch inferieur" zijn.
Toon volledig artikel
Waarom krijg je bij de MS "kan niet" uitspraak toch altijd een vreemd gevoel in de onderbuik?
IE uit Windows kon/kan niet, MP uit Windows kon niet maar toch wel.
ODF kan niet vanwege incompatibele onderdelen, een hele hoop "wil niet", dat is MS ten top.
Kan niet is dood, wil niet die leeft nog.
Microsoft ziet ook wel dat als ze de ODF standaard moeten gaan toepassen, ze heel office op de schop kunnen gooien. En aangezien Microsoft office het meest gebruikte pakket is (wereldwijd) denken ze het patent op alleenrecht in standaarden te hebben. Oftewel; Microsoft bepaalt de standaard en de rest mag volgen. Ongeacht of deze standaard ook maar enigszins toe te passen is door andere partijen.
Hier vind ik, mag ernstig bezwaar tegen worden gemaakt en IBM heeft andere bedrijven aan haar zijde nodig om een flinke vuist tegen microsoft te maken. Hopelijk volgen er meer, want de arrogantie van microsoft in deze kwestie is uiterst triest.
Microsoft ziet ook wel dat als ze de ODF standaard moeten gaan toepassen, ze heel office op de schop kunnen gooien.
Als dat zo zou zijn, leg mij dan eens uit hoe de Belgische federale overheid met succes is overgestapt naar ODF, waarbij MS Office nog steeds wordt gebruikt om de documenten te bewerken.
Omdat er een plugin voor Office beschikbaar is waarin je ODF documenten kan opslaan. Deze plugin is één van de beste ODF document generatoren op het moment, echter kan office niet al haar functionaliteit kwijt in het ODF formaat (zoals review). Vandaar OOXML. Ben het wel met IBM eens dat ze beter de features in ODF kunnen zetten, i.p.v. met OOXML te komen.
Omdat er een plugin voor Office beschikbaar is
Juist, en dat geeft aan dat MS Office niet volledig op de schop hoeft om ODF te kunnen ondersteunen...
echter kan office niet al haar functionaliteit kwijt in het ODF formaat
Maar is dat een probleem, en zo ja, voor wie? Ondersteuning van ODF sluit ondersteuning van andere bestandsformaten zoals OOXML niet uit. MS-Office-gebruikers die bepaalde specifieke functionaliteit nodig hebben kunnen ervoor kiezen in zo'n formaat op te slaan, of dat nu een internationale standaard is of niet. Ik snap wel dat Microsoft OOXML graag tot ISO-standaard verheven zou zien, maar dat is eerder in het belang van de fabrikant dan in dat van de gebruikers.
Juist, en dat geeft aan dat MS Office niet volledig op de schop hoeft om ODF te kunnen ondersteunen...
Zolang je een dergelijk plugin alleen gebruikt om wat eenvoudige word documenten voor publicatie naar ODF om te zetten is het wel te doen.
Verder gebruikt de begische overheid zover ik weet de Sun ODF plugin en dat is eigenlijk een OpenOffice engine die eigenlijk helemaal niet OOXML kan converteren maar die op het interne binaire geheugenformaat van MS Office werkt (dat lijkt namelijk nog op .doc en de OOo engine bevat daar natuurlijk al jaren een uitgebreide converter voor).
Bovendien werkt dat voor complexere documenten ook bepaald niet 100% en zal een dergelijke plugin bij een MS office release niet meer hoeven werken omdat Microsofts interne geheugenformaat waarschijnlijk steeds minder zal blijven lijken op de oude binaire formaten
Zolang je een dergelijk plugin alleen gebruikt om wat eenvoudige word documenten voor publicatie naar ODF om te zetten is het wel te doen.
Er is bij de invoering uitvoerig getest met een verzameling documenten zoals die bij de federale overheid de ronde doen, dus met de functionaliteit die daar daadwerkelijk wordt gebruikt. Het is aan te nemen dat het om wel wat meer gaat dan "wat eenvoudige Word-documenten".
en zal een dergelijke plugin bij een MS office release niet meer hoeven werken
Dat kan best kloppen als Microsoft voor ondersteuning van ODF afhankelijk zou blijven van het werk van Sun. Maar als de ontwikkelaars van dat bedrijf, zonder gedetailleerde kennis van de opbouw van MS-Office, al een fatsoenlijke ODF-plugin kan programmeren, hoeveel beter moeten de programmeurs van Microsoft dan wel in staat zijn om ODF-ondersteuning te implementeren, ook in nieuwere versies. Hoe dan ook, dat het pakket er geheel voor op de schop zou moeten is pertinente onzin.
Maar als de ontwikkelaars van dat bedrijf, zonder gedetailleerde kennis van de opbouw van MS-Office, al een fatsoenlijke ODF-plugin kan programmeren, hoeveel beter moeten de programmeurs van Microsoft dan wel in staat zijn om ODF-ondersteuning te implementeren, ook in nieuwere versies
De Sun ontwikklaars beschikken juist over zeer gedetailleerde kennis over de opbouw van het interne openOffice format en het converteren daarvan door OpenOffice omdat dit in essentie de oude binaire .doc files zijn die Openoffice al enkele jaren naar ODF converteert. Microsoft heeft die kennis juist niet in huis omdat zij nooit hun binaire formaten naar ODF hebben geconverteerd.
Essentieel is verder dat er nog maar beperkte kennis is om de conversie te doen op basis van de pure XML files (dus zonder MS office). Er is een door Microsoft gesponserd OSS project om een converter van OOXML naar ODF te maken op Sourceforge maar die halen nog niet de kwaliteit van de conversieplugin van Sun op basis van het Office binaire formaat.
De huidige conversie is dus een combinatie van MS Office die OOXML files kunnen converteren naar een intenre binaire representatie en Sun die de binaire MS Offcie representatie kan converteren naar ODF (waarbij overigens echter niet alle functionaliteiten 100% worden behouden). Heel bijzonder maar ook erg onhandig op de langere termijn. Die conversie is niet vendor onafhankelijk zoals bijvoorbeeld een Sourceforge plugin dat wel zal kunnen zijn.
[quote]De Sun ontwikklaars beschikken juist over zeer gedetailleerde kennis over de opbouw van het interne openOffice format[quote]
bovenstaande moet zijn:
De Sun ontwikkelaars beschikken juist over zeer gedetailleerde kennis over de opbouw van het interne MS Office format...
Dus wordt het:
De Sun ontwikkelaars beschikken juist over zeer gedetailleerde kennis over de opbouw van het interne MS Office format...
Microsoft heeft die kennis juist niet in huis
?????
Je laat nu wel het stukje weg "en het converteren daarvan door OpenOffice"
OpenOffice is al jaren bezig met conversie van de binaire formaten naar hun formaten en dus ook ODF. Daar kennen zee de binaire Office formaten goed en weten ze hoe ze die zo optimaal mogelijk naar hun eigen formaten zoals ODF kunnen converteren en welke beperkingen daar bijvoorbeeld aan zitten. Het heeft overigens aardig wat jaren geduurd voordat de conversieniveua van OOo op het huidige niveau is gekomen.
Microsoft heeft die kennis niet. Ze kennen naturlijk hun eigen interne binaire formaat wel heel goed maar hebben dat nooit naar ODF hoeven converteren omdat MS Office geen ODF exporteert en ook niet de OOo/starOffice voorloper ervan.
Essentie is dat dit geen "OOXML naar ODF" plugin is maar een "MS Office binary rich text format naar ODF". Daar heeft bijvoorbeeld een onafhaneklijke Office leverancier zoals corell geen zak aan. Deze plugin werkt alleen op MS Office en kan dus niet even omgebouwd worden om op Wordperfect te werken
Microsoft heeft die kennis niet. Ze kennen naturlijk hun eigen interne binaire formaat wel heel goed maar hebben dat nooit naar ODF hoeven converteren
Wat wil je daarmee nu eigenlijk zeggen? Omdat Sun veel ervaring heeft met het converteren van MS-Officebestanden lukt het dat met een plug-in, maar omdat de programmeurs van Microsoft die ervaring niet hebben zou voor ODF-ondersteuning heel MS-Office op de schop moeten? Hoe moeten diezelfde programmeurs dan in 's hemelsnaam de conversie van diezelfde gegevensstructuren naar een ander XML-formaat, OOXML, voor elkaar krijgen?
Wat ik aangeef is dat deze plugin methode niet goed is.
Microsoft vertaald de OOXML naar een intern binair formaat en Sun het interne binaire formaat naar ODF. Dat is niet een juiste methode omdat deze niet toepasbaar is zonder een installatie van MS Office.
Je wilt converters die de OOXML naar ODF converteren en vice versa ook zonder de aanwezigheid van MS Office en zonder afhankelijkheid van een intern formaat.
Je wilt converters die de OOXML naar ODF converteren en vice versa ook zonder de aanwezigheid van MS Office en zonder afhankelijkheid van een intern formaat.
Op zich wel, maar die zijn er ook vast al wel :) Los daarvan, je hebt waarschijnlijk een van beide pakketten al (MS Office vs. OOo) dus waarom zou je daar geen gebruik van maken? Waarom nog eens een extra hele zware applicatie installeren die beide formaten moet kunnen begrijpen als je al een zware applicatie hebt die beide formaten begrijpt?
Ik ben het met je eens dat zo'n tooltje handig zou kunnen zijn (b.v. op een mailserver, eentje die attachments automatisch omzet naar een gekozen formaat) maar echt heel spannend is dat op dit moment niet als je toch al een app hebt die beiden kan lezen.
Dat is niet een juiste methode omdat deze niet toepasbaar is zonder een installatie van MS Office.
Waar praten we nu eigenlijk over? Volgens mij ging het over ondersteuning van ODF in MS-Office. Daar heeft Sun een goed werkende oplossing voor met een plugin. De (goedbetaalde en vakbekwame, neem ik toch aan) programmeurs van Microsoft zouden, met de hun wél ter beschikking staande interne documentatie en broncode van MS-Office, en met hun ervaring bij het converteren van de interne gegevensstructuren naar het vergelijkbare bestandsformaat OOXML, in staat moeten zijn om op basis van eenzelfde aanpak een nog betere oplossing te implementeren. En dan zou dat niet kunnen omdat, bij de ondersteuning van ODF in MS-Office, het pakket waar het juist om gaat uit de vergelijking gehaald moet worden???
Sorry hoor, je redeneringen worden wel erg moeilijk om nog te volgen. Het heeft er nog het meeste van dat je je in een hoek hebt gepraat en dat probeert te verhullen door met onzinverhalen de aandacht af te leiden.
Wat ik aangeef is dat deze plugin methode niet goed is.
Microsoft vertaald de OOXML naar een intern binair formaat en Sun het interne binaire formaat naar ODF. Dat is niet een juiste methode omdat deze niet toepasbaar is zonder een installatie van MS Office.
Je wilt converters die de OOXML naar ODF converteren en vice versa ook zonder de aanwezigheid van MS Office en zonder afhankelijkheid van een intern formaat.
Dat hangt er vanaf, er is behoefte aan beide (nu neem ik even aan dat de sun converter inderdaad werkt volgens MS-BRTF-> ODF).
(1) Voor mensen die met MS-Office moeten werken is het proces MS-INTERNALBINARY <-> ODF, het meest logische. Dit zijn dus gewoon de 'open odf' en 'save as odf' opties. Microsoft heeft zowel volledige toegang tot MS-INTERNALBINARY en ODF dus dit is eenvoudig te implementeren door MS. Om de bekende redenen (bescherming monopolie) weigert MS dit te doen, dus heeft SUN dat gedaan. Hopelijk onstaat er binnenkort een situatie (marktwerking) waarin klanten van Microsoft deze functionaliteit van MS zelf kunnen vragen.
(2) Voor mensen die zich in de periferie van de MS monocultuur bevinden is een standalone converter wenselijk. Het meest voor de hand liggende proces hier is MS-OOXML -> ODF. Gezien de aard van XML zou dit eenvoudig moeten zijn te implementeren (afgezien van het feit dat MS het nodige in MS/ISO-OOXML heeft ingebouwd om dit juist weer te bemoeilijken).
Bij iedere verandering in MS-INTERNALBINARY breekt de compatibiliteit van optie (1), bij iedere verandering in MS-OOXML breekt de compatibiliteit van optie (2). Feitelijk breekt de compatibiliteit van alle opties dus bij iedere nieuwe iteratie van MS-Office. Business as usual dus.
Maakt toch eigenlijk niets uit, wanneer MS de energie in ODF had gestoken was er van een functionaliteit probleem geen sprake. Niemand weerhoud MS om dit alsnog te doen, open standaard open mogelijkheden, omdat dit is samenspraak gaat kan MS er eigenlijk alleen beter van worden. Nu zijn ze alleen maar bezig om eigenwijs over te komen en mensen tegen zich in het harnas te jagen, hoe goed OOXML ook mag zijn, dit werkt alleen maar tegen.
Niemand weerhoud MS om dit alsnog te doen, open standaard open mogelijkheden
Dus jij garandeerd persoonlijk dat Microsoft op niet al te lange termijn wijzigingen kan doorvoeren in ODF om alle mogelijk Office functionaliteit correct te kunnen representeren.
Of bedoel je slechts te zeggen dat ze het in ieder geval mogen voorstellen aan OASIS en dat ze dan maar moeten afwachten of OASIS dergelijk aanpassingen wil maken en dan nog moet afwachten hoe lang dat gaat duren (we wachten ten slotte pas 2,5 jaar op de spreadsheetformules).
De technische kant aan ODF zal misschien niet genoeg ruimte hebben, maar MS heeft wel vanaf het begin aan OASIS mee kunnen doen/werken om hier mogelijkheden aan toe te voegen. MS heeft vast en zeker al de nodige ODF kennis om bij eventuele ISO afkeuring toch nog een basis te hebben. Anders zou MS alles op één kaart zetten.
Daarnaast is MS groot genoeg om er programmeurs tegenaan te gooien, SP1 voor Vista is ook binnen een jaar klaar, ik denk dat dat wel wat zwaarder is.
Daarnaast gaat het niet over details, het gaat over de principes en vragen van klanten, maar MS luistert alleen naar de vragen die ze willen horen of gedwongen worden.
Bij dit type discussies kom je altijd met technische verschillen, deze geen van allen onoplosbaar door gewillige partijen, jij gooit de onwil bij IBM en consorten en ik bij MS.
Beide partijen zullen schuld zijn maar MS heeft een veel slechtere Track Record en is een schuldig bevonden monopolistisch bedrijf waar niet veel blijk van verbetering is.
ODF is ISO goedgekeurd, OOXML niet. ODF heeft het gehaald op zichzelf, OOXML met schandalen niet. ODF heeft klaarblijkelijk voor de meeste gevallen functionaliteit genoeg (genoeg voorbeelden ook serieuze bedrijven), deze kan en mag in open discussie aanpassingen hebben, wat komen we dan nog tekort? (vraag is retorisch, anders komen er weer technische specs die oplosbaar zijn.)
Nou ja, ik juich het alleen maar toe als Baseline met fouten in de ODF spec komt. Daar wordt die spec uiteindelijk alleen maar beter van tenslotte ;) Dat password-verhaal heeft-ie zeker een punt, dan kan chiquer. Maar om dan maar gelijk de hele standaard bij het grof vuil te zetten... HTML en CSS hebben ook verbeterpunten, da's ook helemaal niet zo erg zolang het geen fundamentele kwesties betreft.
Dat gezegd hebbende, als dat password-gebeuren (wat eerder een onvolkomenheid dan een fout is, is mijn indruk) z'n best shot is valt het nogal mee met de veronderstelde inferioriteit van ODF dacht ik zo ;)
Details zijn er om uitgewerkt te worden, niet om als voor en tegen argumenten te gebruiken.
De details moeten door zo veel mogelijk partijen ingevuld worden, alleen met wederzijds respect kan het dan een mooi stukje uitkomst krijgen, wanneer MS zo reageert als Baseline (of erger wat ik verwacht) is er al weinig wederzijds respect en wordt het een "ik weet het beter" oorlog.
Ik vond het bijvoorbeeld veel opvallender dat de ODF specificatie SVG elementen probeert te extenden buiten de w3c standaard om.
Ik vond het bijvoorbeeld veel opvallender dat de ODF specificatie SVG elementen probeert te extenden buiten de w3c standaard om.
Wat ik er zo snel van gezien heb ging dat om extra attributen welke bepalen hoe een afbeelding zich verhoudt tot de omringende content - iets dat in een losse afbeelding niet speelt maar binnen een document wel. Het gaat er ook helemaal niet om dat ze SVG proberen te extenden (over FUD gesproken) maar dat er een aanvulling op is om het bruikbaar te maken binnen een Office-document. Deze aanvullingen zijn duidelijk gespecificeerd en verder niet van toepassing op SVG als geheel, dus ik zie echt het probleem niet.
De kans is groot dat wanneer een Audi-ingenieur een office-applicatie gebruikt, dat dit OpenOffice (ODF) is. Audi migreert helemaal naar Linux, zowel sever-side alsook client side.
Dus zo off topic is dit reclame filmpje niet.
"On [both] the server and workstation sides, we are moving steadily towards a 100% 64-bit Linux environment," says Kienast. "The number of CPUs available for CAE purposes will continue to increase as the hardware costs sink."
Audi is not a Linux newbie; this migration is part of a much longer move to Linux that the company has been making over the past several years, beginning with the deployment of Linux clusters for simulations. "Audi deployed the first Linux cluster of servers in April 2001," says Kienast.
Zie
www.linux.com/feature/59200
www.pro-linux.d...2007/10675.html
www.kriptopolis...-ford-microsoft
www.hoise.com/p...L-06-06-28.html
en zal een dergelijke plugin bij een MS office release niet meer hoeven werken omdat Microsofts interne geheugenformaat waarschijnlijk steeds minder zal blijven lijken op de oude binaire formaten
Natuurlijk niet. Het hele business model van Mircrosoft is erop gebasseerd om zoveel mogelijk incompatibiliteit met de wereld buiten de MS monocultuur op te werpen. Daardoor is het onmogelijk om over te stappen op niet MS producten en hoeft MS zelf dus geen moeite te doen de prijs en/of kwaliteit van haar producten te verbeteren.
Een vrij beschikbare ODF converter zal het makkelijker maken om weg te migreren van Office, dus beschouw het als een zekerheidje dat Mircosoft in een volgende versie van Office hiermee de compatibiliteit zal breken. Net zoals MS de compatibilteit zal breken tussen MS-OOXML en ISO-OOXML.
Zoals Bolleke al aangeeft zijn de technische tekortkomingen die jij bij ODF meent te bespeuren eerder tekortkomingen in je eigen kennis. ODF is technisch superieur aan OOXML.
Dat neemt niet weg dat de voornaamste argumenten tegen OOXML niet technisch, maar economisch van aard zijn. Met OOXML zit je vast aan 1 aanbieder (Microsoft) die geen prikkels heeft om de prijs/kwaliteit te verbeteren, consumenten kunnen toch niet overstappen.
Binnen het open standaarden idee (ODF dus) is het mogelijk om te switchen van aanbieder. Aanbieders zullen er dus alles aan moeten doen om zo goed mogelijk kwaliteit voor een zo laag mogelijk prijs te leveren, anders verliezen ze hun klanten.
Vergelijk de ontwikkeling van Ford en van Trabant. In al die jaren dat de kwaliteit van Trabant constant laag bleef ging die van Ford steeds omhoog. De oorzaak ervan was dat Trabant toch geen concurrenten had, die hadden simpelweg geen noodzaak hun kwaliteit te verbeteren. Voor Ford was die noodzaak er wel, anders waren ze failliet gegaan omdat hun klanten waren overgestapt op de prodcuten van concurrenten.
Het fundament onder onze markteconomie is de mogelijkheid tot vrije concurrentie. Dit is op basis van gesloten, aan Microsoft gebonden, standaarden niet mogelijk.
Een vrij beschikbare ODF converter zal het makkelijker maken om weg te migreren van Office, dus beschouw het als een zekerheidje dat Mircosoft in een volgende versie van Office hiermee de compatibiliteit zal breken
Je begrijpt het niet.
De Sun converter werkt alleen op Office en niet op losse OOXML files.
Het is juist de converter die de Office lockin creert
Je begrijpt het niet.
Dat _jij_ tegen _mij_ zou zeggen dat _ik_ het niet begrijp doet mij denken aan een uitspraak die Bill Gates naar aanleiding van de grote hoeveelheid spam mailtjes die hij kreeg met tips over hoe hij snel rijk kon worden deed: It would be funny if it wasn't so damn annoying
De Sun converter werkt alleen op Office en niet op losse OOXML files.
<cynisch>Jo echt?</cynisch>
Het is juist de converter die de Office lockin creert
Als Office gebruikers hun bestanden vrij als ODF kunnen opslaan zitten zij daarmee niet meer aan Mircrosoft vast bij de volgende upgrade ronde, producten van andere aanbieders kunnen dan net zo makkelijk hun bestanden openen. Dit is ook de oorzaak dat MS juist geen ODF wil ondersteunen met Office.
Al die moeite rondom OOXML is erop gericht dat Office gebruikers hun bestanden niet als ODF gaan opslaan en zo vendor lockin te behouden. En nu ga jij beweren dat als Office gebruikers hun bestanden als ODF kunnen opslaan dit juist zou lijden tot vendor lockin?
Als je dit soort dingen van jezelf terugleest is er dan nooit sprake van enige twijfel en/of schaamte?
Ach, alon is here en de minnetjes regen ook.
Al die moeite rondom OOXML is erop gericht dat Office gebruikers hun bestanden niet als ODF gaan opslaan en zo vendor lockin te behouden
Aangezien iedereen OOXML gewoon vrijelijk kan implementeren is dat bepaald geen vendor lock in. Als er al een veodor lock in bestaat dan is dat omdat MS Office meer functionaliteit levert dan andere vendors doen en dat gebruikers daarom MS Office prefereren. Dat concept alleen al is echter voor jou natuurlijk onaanvaardbaar want dat zou bijvoorbeeld betekenen dat ODF dat niet alle MS Office functionaliteit kan ondersteunen ook niet voldoet...
youtube.com/wat...h?v=oNcAjS7LqKM
Ach, alon is here en de minnetjes regen ook.
Baseline doet zogenaamd een poging een pro-Microsoft verhaal op te hangen. In feite is hij enkel bezig iedere discussie dmv een plethora van ongerelateerde copy/pastes en slechte vertalingen van Microsoft blogs in de kiem te smoren.
Zijn discussie methodiek volgt meestal het volgende schema. We beginnen met een situatie waar er kritiek is op OOXML. Vervolgens schreeuwt Baseline om het hardst (en zonder onderbouwing) dat dit volslagen onzin is en claimt dat dezelfde kritiek juist veel harder op ODF van toepassing is (waar we het niet over hadden). Nu is de kritiek op OOXML niet ontkracht maar hebben we het over ODF. Vervolgens gaan mensen de kritiek op ODF ontkrachten. Op dit moment komt Baseline met een volslagen andere beschuldiging op de proppen, waardoor de discussie zich opnieuw verplaatst. Na verloop van tijd staat de hele pagina vol met ongerelateerde onzin. Een voorbeeld van deze taktiek aan het werk is hier te vinden.
Aangezien dit zich steeds herhaalt krijg ik steeds meer de indruk dat Baseline ook wel weet dat de mensen waar hij tegen is betere argumenten hebben en/of beter in staat zijn die argumenten te verwoorden maar dat hij simpelweg als doel heeft iedere discussie onmogelijk te maken.
Naast de 'waterval van onzin' taktiek heeft Baseline nog een andere strategie om iedere normale discussie in de kiem te smoren. Dat is het minwapen.
Er waren momenten (hier en hier bijvoorbeeld) dat ik meteen naar het posten van een comment al op min tien stond. Als er verder weinig mensen aanwezig zijn en Baseline rustig tussen door onder zijn andere accounts post weet ik dan wel hoe laat het is.
Ik zit hier nog niet zo lang en heb gewoon 1 account, gezien de situatie is dat eigenlijk al teveel. Aanvankelijk deed ik niet aan modereren, nu zet ik gewoon overal een plusje achter. En dan heeft men nog het lef MIJ van minnen te beschuldigen.
Het is opvallend dat je voorbeelden geeft van discussies waar mijn inhoudelijk on topic reacties (die aan de inhoud van het artikel refereren) veel veel veel meer minnetje hebben gekregen dan jou over het algemeen off topic of in ieder geval niet aan het artikel refererende reacties (anders gezegd je anti-MS rants).
Tja, ofwel de inhoud van je on topic reacties snijdt dan blijkbaar niet zo veel hout ofwel er zijn er hier meer die je discussie taktiek, zoals alon heeft omschreven, doorzien. Vandaar dus de minnetjes.
Zou het kunnen dat "baseline" inderdaad niemand anders dan de (in)famous "Albert" is ?
Dat houd ik beslist wel voor mogelijk, gezien de treffende overeenkomsten in z'n "modus operandi" hier op WebWereld.
Overgens begrijp ik de kennelijke boosheid niet om de gegeven op- en aan-merkingen op de warez/systemz van ms.
Iemand die goed onderbouwd (en beleefd !) kritiek heeft op de door mij gemaakte/geschreven programs en/of andere technische zaken ben ik daar zelfs heel dankbaar voor, omdat ik die foutjes/tekortkomingen er dan uit kan gaan halen. Zo iemand is dan in feite bezig met beta-testing en dat is onmisbaar bij serieuse ontwikkeling van elk ICT-project.
Waardoor er uiteindelijk betere programs/systems kunnen worden gemaakt en daar gaat het toch om. Het is helemaal niet zo erg om een foutje te maken - maar wel om te weigeren dat foutje onder ogen te zien !! En helemaal om degenen die dit doen dan zelfs te gaan beledigen...
Maar blijkbaar is ms (alsmede baseline/Albert) totaal niet ge-interesseerd in verbetering van hun sofwarez/systemz - maar slechts op het verkopen van deze evidente cripplewarez. En, misschien nog belangrijker, het behouden van hun total(itair)e vendor-lockin over wat hun betreft heel de (ICT) wereld...
En daar moet een einde aan komen, liever gisteren dan vandaag.
Het interesseert mij persoonlijk niet of Baseline en Albert dezelfden zijn, net zoals het mij niet boeit of Theodoor en Toiletpapier dezelfden zijn. Het gaat om argumenten.
Ik wil graag met Baseline in discussie over dit onderwerp, maar ik zou graag zien dat hij zijn claims dat OOXML technisch superieur is aan ODF eens op een goede manier onderbouwt. En daarmee bedoel ik dus niet de tactiek waar hij zich tot dusver van heeft bediend, te weten:
- het presenteren van zijn eigen onbegrip als fouten in ODF
- het hameren op functionaliteit waarvan ik en volgens mij ook OASIS vindt dat ze in de applicatie thuishoort en niet in het formaat
- het focussen op de paar kleine foutjes/onvolkomenheden/verbeterpunten die je in elke standaard wel kunt vinden
Als je claimt dat iets "technisch superieur" is dan verwacht ik een duidelijke en technisch gedetailleerd onderbouwde uiteenzetting over het hoe en waarom. Anders moet en mag je dat soort dingen niet roepen, IMHO. Tot nu toe heb ik - een webprogrammeur die slechts heel zijdelings met deze materie te maken heeft - zijn opmerkingen kunnen weerleggen door domweg even de documentatie erbij te pakken en gewoon goed te lezen (ja, ik heb al mijn antwoorden ter plekke moeten opzoeken, want ik ben dus ook geen expert hierin maar een relatieve boerenlul die wel gewoon een document kan lezen). Zolang Baseline op dit gebied niet met echte argumenten komt moet ik helaas aannemen dat hij ook geen expert is maar net zo goed maar wat roept. Maar erger dan ikzelf, want ik zoek het tenminste nog even na.
Disclaimer: "hij" kan ook een "zij" zijn natuurlijk ;)
In de onderstaande reacties staat heel duidelijk waarom de SVG ondersteuning in ODF brak is en de MathML ondersteuning in ODF niet erg geschikt is voor gebruik in Office documenten en ook nog na jaren niet heeft geleid tot de bedoelde interoperabiliteit in MathML in ODF implementaties wat toch het doel zou zijn van het hergebruik van standaarden.
Verder heb ik aangegevens dat DrawingML veel uitgebreider is dan bijvoorbeeld ODF draw (je kunt er bijvoorbeeld SVG naartoe converteren wat je met ODF draw niet kunt) maar is dat verder best complex en niet even snel in een comment af te handelen.
Daarnaast heb ik aangegeven dat OOXML functionaliteit bevat waardoor het backwards compatibiliteit heeft en waardoor je een betere performance kan krijgen dan met ODf files wat voor Microsoft ook belangrijke zaken zijn om in een Office formaat te hebben.
Is OOXML superieur als geheel. Dat hangt dus af wat je wil. Vind je de extra features en mogelijken die in OOXML zitten zinvol en nuttig om te gebruiken dan misschien wel. Vind je ze overbodig/onnodig dan misschien niet.
Ik ga die discussie niet uit de weg.
het focussen op de paar kleine foutjes/onvolkomenheden/verbeterpunten die je in elke standaard wel kunt vinden
Het is lastig om veel issues naar voren te brengen in een paar comments. Bovendien is een algemeen issue in ODF het ontbreken van info die je nodig hebt voor echte interoperabiliteit. Niet iets wat je makkelijk kan presenteren. Opvallend is dat je zelf bijvoorbeeld zelf verschillende keren hebt gerefereerd aan de OOo documentatie als kennis bron over een voorbeeld issue mbt ODF wat ik eigenlijk sprekend vind omdat veel van de info die in de standaard hoort alleen bij OOo te vinden is en ontbreekt in de standaard.
@Baseline:
Het is lastig om veel issues naar voren te brengen in een paar comments.
Helemaal mee eens. Mijn - zeer serieuze - aanbod om dit te verplaatsen naar een dedicated blog staan nog steeds. Server en software zijn voorhanden, ik heb zelfs nog wel een domeintje liggen dat we daarvoor zouden kunnen gebruiken :) Je mag me altijd mailen: bolleke MONKEYTAIL voeljeniksvan PUNT nl :)
[quote]Opvallend is dat je zelf bijvoorbeeld zelf verschillende keren hebt gerefereerd aan de OOo documentatie als kennis bron over een voorbeeld issue mbt ODF wat ik eigenlijk sprekend vind omdat veel van de info die in de standaard hoort alleen bij OOo te vinden is en ontbreekt in de standaard.[/quote]
Eh, alleen ik heb dat een paar keer gedaan, en dan in reactie op dingen die - dat geeft ik grif toe - in ODF niet direct duidelijk staan, of waarbij het mij in elk geval aan de kennis ontbreekt om die goed te interpreteren. Aangezien jij te pas en te onpas functionaliteit[/quote] in MS Office aanhaalt om het formaat ODF af te kraken is dit een beetje een geval van de pot en de ketel dunkt me.
[quote]In de onderstaande reacties staat heel duidelijk waarom de SVG ondersteuning in ODF brak is en de MathML ondersteuning in ODF niet erg geschikt is voor gebruik in Office documenten en ook nog na jaren niet heeft geleid tot de bedoelde interoperabiliteit in MathML in ODF implementaties wat toch het doel zou zijn van het hergebruik van standaarden.[/quote]
Dat MathML voor verbetering vatbaar is is iedereen het wel over eens volgens mij. De grap is natuurlijk dat een ODF document direct profiteert van die verbetering, juist doordat ze er een extern formaat voor gebruiken. Tja. Da's een keuze.
[quote]Daarnaast heb ik aangegeven dat OOXML functionaliteit bevat waardoor het backwards compatibiliteit heeft en waardoor je een betere performance kan krijgen dan met ODf files wat voor Microsoft ook belangrijke zaken zijn om in een Office formaat te hebben.[/quote]
Daarnaast heb ik al *ugh* keer betoogd dat dat soort dingen niet in het formaat horen maar in de applicatie. Prima, we verschillen hierover van mening. Erken dat dan gewoon en blijf het niet als een mantra herhalen tegen anderen, dat is hoogst irritant. De performance zit *nooit* in het formaat maar *altijd* in de applicatie. Wedden dat ik een bagger-trage spreadsheetapplicatie kan schrijven op basis van OOXML?
Beste Bolleke in reactie op 06-02-2008 23:00
Het gaat om argumenten.
En daar heeft u natuurlijk helemaal gelijk in ! Dat is ook wat mij aan baseline (borderline ? ;-) ) zo ontzettend ergert: allerlei totaal uit de lucht gegrepen/niet onderbouwde/gewoon puur onware "argumenten". (aka FUD).
Die mij heel sterk aan "Albert" doen denken. Net als aan "beef stalmer", u weet wel, de baas van die sofwarez distributerende P.R.-firma, die nog steeds denkt "de beste" te zijn. Zij het dan vooral voor virus e.d. makers... ;-)
En die nog steeds schijnen te denken dat vrij slechte warez automagically beter worden door er veel reclame voor te maken, door deze middels koppelverkoop op te dringen aan de klanten en vooral door alle andere, bewijsbaar technisch veel betere alternatieven de grond in te boren. Alleen jammer voor die reclame, FUD en vooral veel misbaar makende figuren, dat wij daar echt niet meer intrappen.
Zelf ben ik er nooit ingetrapt, als Linux (o.a. kernel) Hacker van zowat 't eerste uur. Net als de Romeinen in de oudheid wantrouw ik het intens, als te veel macht in handen van een te klein groepje of zelfs maar 1 enkele persoon (b.v. een "keizer", "president" of... een "ceo") valt. Dit heeft namelijk zonder 1 uitzondering altijd hoogst ongewenste effecten gehad. Zie de geschiedenis er maar op na.
Wie meent dat er nog iemand echt oprecht gelooft in al die oude leug... , pardon, "reclame"-uitingen van "die firma", die vergist zich schromelijk. Zie o.a. het me-2, pardon "vista"-fiasco...
Wij kunnen namelijk wel echt lezen, ook en vooral alle objectieve, technisch goed onderbouwde publicaties over dit onderwerp. En dat zijn me er toch veel...!
Afgezien dat het gijzelen (door vendor-lockin) van onze PC's, data en overheden nu maar eens definitief afgelopen moet zijn. En wij de controle over ons leven terug moeten nemen, deze vorm van verkapte moderne (digitale) slavernij heeft al veel te lang geduurd en is bovendien volstrekt intolerabel.
Alleen daarom al: Zo snel mogelijk (proberen) over te schakelen naar Open_Standards/Source in ons belang - niet het belang van welke firma dan ook, omdat dit juist te koste gaat van ons belang. En laat nu iemand maar eens proberen om deze stelling van mij (maar dan wel goed onderbouwd !) te weerleggen. Ben benieuwd...!
Grtz. D.I.
Disclaimertje: de door mij gebruikte "wij"-vorm betekent geenzins dat dit de mening van iedereen zou vertegenwoordigen want dat doet het niet, het is slechts een manier van omschrijven en geeft slechts mijn mening weer. Ook wordt er nog even fijntjes op gewezen dat er in dit berichtje geen enkele firma bij naam genoemd wordt. Maar: "Wie de schoen past trekke hem aan..."
Dit disclaimertje is ter voorkoming van einde-, inhouds- en humor- loze "discussies". Die toch al veel te vaak voorkomen, helaas...
@Diogenes_ishes: ach, wat mij altijd irriteert is dat als het om iets van OOXML gaat bepaalde personen om hardst roepen dat ODF nog veeeeeeeel slechter is - alsof dat een vergoeilijking voor de "eigen" fouten zou zijn.
Mijn moeder zei altijd: "kijk nou eerst maar eens naar jezelf". En dat is hier erg van toepassing. Merk op dat het artikel over OOXML gaat en de kritiek daarop, maar dat ik zeeen van tijd kwijt ben om kritiek op ODF te weerleggen - en ik zoek het ook maar ter plekke op, want ik ben absoluut geen expert die die kennis paraat heeft (al begint dat langzaam te veranderen *lol*).
Waarom ik de moeite dan toch neem? Google maar eens op glyph-orientation-vertical (het inmiddels beruchte voorbeeld) en je vindt vooral postjes op Webwereld waarin Baseline/Albert "uitlegt" dat dit een duidelijke fout in ODF is en dat dat dus een reden is het niet te willen gebruiken. Ik heb - zoals ook jij weet - ten overvloede aangetoond dat deze argumentatie compleet foutief is en nergens op slaat, maar als ik het niet blijf weerleggen vindt de argeloze internetter via Google slechts onwaarheden over ODF.
Kortom, ik probeer FUD anno 2008 tegen te gaan :)
als het om iets van OOXML gaat bepaalde personen om hardst roepen dat ODF nog veeeeeeeel slechter is - alsof dat een vergoeilijking voor de "eigen" fouten zou zijn
Misschien is het je niet opgevallen maar het eerst wat er bij dit artikel gebeurde was gezeur over dat Micrsoft gewoon ODF zou moeten toepassen.
Bovendien daag je me zelf uit door te beweren dat de tekortkomingen in ODF geen echte tekortkomingen waren maar gewoon tekortkomingen in mijn eigen kennis waren.
Dan is het dus al gauw logisch om een vergelijking te maken tussen ODF en OOXML en bijvoorbeeld aan te geven wat voor zaken er niet in ODF zitten die Micrsoft wel in Office zou willen gebruiken.
Ik heb zelfs heel duidelijk aan gegeven in enkele reacties dat ik vind dat er gewoon twee formaten moeten kunen zijn en een keuze voor een Office formaat moet afhangen van hoe je het betreffende formaat wilt gebruiken en dat een verplichte keuze voor ODF daarom voor mij niet aan de orde is.
Ik heb zelfs heel duidelijk aan gegeven in enkele reacties dat ik vind dat er gewoon twee formaten moeten kunen zijn en een keuze voor een Office formaat moet afhangen van hoe je het betreffende formaat wilt gebruiken en dat
Twee standaarden die hetzelfde willen afdekken, is meestal een nadeel. Zoals inch en meter, en noem maar op. Het gebeurt soms, maar het is niet wenselijk. Voortdurend moet er worden geconverteerd, kost effort, kost geld, kost moeite, leidt regelmatig tot fouten.
Maar soms gebeurt het toch, uit politieke gronden.
een verplichte keuze voor ODF daarom voor mij niet aan de orde is.
Een keuze die verplicht is geen keuze. Standaarden dienen er juist toe om keuze mogelijkheden te beperken.
Wat voor jou aan de orde is, is voor ISO of de wereld geen halszaak. Ik begrijp niet wat je hiermee wilt zeggen? Ik hoor graag wat je daarmee bedoelt.
Dan is het dus al gauw logisch om een vergelijking te maken tussen ODF en OOXML en bijvoorbeeld aan te geven wat voor zaken er niet in ODF zitten die Micrsoft wel in Office zou willen gebruiken.
...en tot nu toe heb ik gehoord: pijltjes aanpassen in PowerPoint, een functie die ODF op geen enkele wijze onmogelijk maakt.
Over de kwaliteit van MathML en SVG-ondersteuning heb je ongetwijfeld helemaal gelijk, ik gebruik dat nooit en weet er dus te weinig van om daar iets zinnigs over te kunnen zeggen.. Wat me dan wel leuk lijkt is als je met een OOXML document kunt komen waarvan de conversie naar ODF een heel fout resultaat oplevert.
Voor de rest vind ik het allemaal niet zo boeiend meer, je focust je op een paar functies die vrijwel niemand serieus zal gebruiken (graphic artists tekenen niet in Word, en wiskundigen gebruiken LaTex oid). Ja, het kan vast beter, geef maar een voorbeeld en dan kan OASIS daarmee aan de slag. Maar zoals jij het brengt lijkt het wel alsof 99% van de bestaande MS Office documenten onbruikbaar worden als ze naar ODF moeten, en dat is toch gewoon niet waar? Als we het daar nou eens over eens worden, dan kunnen we daarna gaan kijken hoe het met die paar punten zit waar je wellicht domweg gelijk mee hebt :-)
Google maar eens op glyph-orientation-vertical (het inmiddels beruchte voorbeeld) en je vindt vooral postjes op Webwereld waarin Baseline/Albert "uitlegt" dat dit een duidelijke fout in ODF is en dat dat dus een reden is het niet te willen gebruiken.
Dat is dan gelijk een archetypisch voorbeeld aan hoe Baseline zelf aan zijn informatie komt. Hoe de Baseline's van deze wereld elkaar van informatie voorzien...
Het ging ook niet om een melden van een fout in ODF maar over een stuk ODF specificatie met volgens mij onvoldoende informatie om deze functie te kunnen implementeren.
En Bolleke heeft vervolgens uitgelegd hoe dat wel te doen. En dat de functie overeenkomstig was aan vergelijkbare functionliteit in bijvoorbeeld SVG en aan de hand van voorbeelden (waarbij hij het toruwens zelf ook nog anders deed). Zo evident was het dus zeker niet. De info in de ODF spec was zonder meer te summier voor implementatie maar Bolleke heeft me overtuigd dat iemand met kennis van de materie (tekstrotatie) er wel redelijk eenvoudig uit zou zijn gekomen.
Overigens was daarbij nog steeds aan de orde dat het nut van de functie door de inperking waardebereik (uit of automatic) onduidelijk is gebleven in die discussie.
Bollek gaf aan dat het waardebereik van glyph-rotation mogelijk in de toekomst kan worden uitgebreid maar dan is het niet duidelijk waarom het item nu al zonder zinvolle waarde in de spec is opgenomen
Volgens mij is Bolleke, en ben ook ik enkele punten van zwakte in ODF met je eens. Niets is perfect, ook ODF niet, en ook OOXML niet, ook de zwaktes daarin zijn reeds besproken.
Het was een interessante discussie.
Bij ODF wordt gewerkt aan uitbreiding, ook dat heb ik reeds aangegeven, het werk aan de formula's in spreadsheet, volledig conform ISO, bijvoorbeeld. Erg positief, ruim meer dan 300 functies zijn gedefinieerd, er volgen er nog honderd.
Bij OOXML, wordt neem ik aan, hard gewerkt om tegemoet te komen aan de pijnpunten uit de vorige ballot-meeting (dit waren er 3500?, maar ook veel duplicaten). We zijn erg benieuwd. Binnen enkele weken weten we het. Het moet een flinke klus zijn geweest voor Ecma om dit klaar te krijgen.
Het nadeel van de Fast track is dat het bijna onmogelijk is om tijd te winnen, want impliciet houdt de fast track in dat de standaard eigenlijk gereed is behalve een paar puntjes, misschien. En als dat niet zo is, dan valt het doek over deze standaard, en moet het ISO traject opnieuw worden ingegaan.
Het is echter niet ISO dat in dit geval op Fast Track heeft aangedrongen, dus als de standaard sneuvelt dat ligt dit geheel en al bij Ecma, dat zou erg jammer zijn.
Maar goed, misschien zijn de national bodies erin geslaagd om de 6000 originele pagina's en de 2800 additionele pagina's te bestuderen, en hebben ze daarin een bevredigende oplossing gevonden voor de pijnpunten uit de vorige ballot.
Als alle pijnpunten worden opgelost, er zijn er enkele die ik belangrijk vindt, dan is OOXML een aardige standaard, met nog steeds enkele zwakten, en ook dan blijft het bezwaar dat het een redundante standaard is.
Ik stel voor dat we deze discussie volgende week opnieuw voeren, als Microsoft repliceert op de aanval van IBM, en dat we hem ook nog een keer opnieuw voeren als de 28ste de uitslag van de ballot meeting is.
En mischien kunnen we hem ook nog een keer opnieuw voeren binnenkort bij het 112 jarig bestaan van IBM, en ook nog een keer op de verjaardag van Bill Gates.
Ik weet zeker dat de gemiddelde webwereld lezer dit een fantastische discussie vindt, die neit diep genoeg kan worden uitgespit.
Ook dit maal is er enorme energie gestopt in meer dan 100 reacties. Ik benbenieuwd hoeveel er nog worden gehaald voordat hij ook uit het vakje:"Meeste reacties (afgelopen 72 uur)" is weggezakt.
Mooi is ook dat reacties niet meer worden dichtgeklikt, ik merk dat dat een hoop venijn uit de reacties haalt. Het boksball-effect is verdwenen
Maar goed, misschien zijn de national bodies erin geslaagd om de 6000 originele pagina's en de 2800 additionele pagina's te bestuderen, en hebben ze daarin een bevredigende oplossing gevonden voor de pijnpunten uit de vorige ballot.
Ik heb gehoord dat op Malta dit gebeurt door het klooster van tempelridders, samen met de maagd van meneer pastoor, en de hoofdonderwijzer die in het algemeen als deskundige wordt beschouwd (hij heeft een cursus in WP5.1 gehad, en heeft prachtige macro's geprogrammeerd). Verder doet de juffrouw van de veerboot maatschappij ook mee, want zij wordt over het hele eiland gezien als een autoriteit op het gebied van Windows 98.
Als ik meer tijd zou hebben dan zou ik met plezier een boek hebbeng eschreven over de wederwaardighedenv an het ISO-bestaan op Malta.
Ooit van de Italiaanse schrijver Guareschi gehoord? Zijn fantastische boek: "Il piccolo monde de Don Camillo". Heerlijk.
Het ging ook niet om een melden van een fout in ODF maar over een stuk ODF specificatie met volgens mij onvoldoende informatie om deze functie te kunnen implementeren.
En Bolleke heeft vervolgens uitgelegd hoe dat wel te doen.
Dat nog niet eens, ik heb gewoon opgesomd wat er stond en wat engelse woorden vertaald voor je :)
En dat de functie overeenkomstig was aan vergelijkbare functionliteit in bijvoorbeeld SVG en aan de hand van voorbeelden (waarbij hij het toruwens zelf ook nog anders deed).
Nee - ik deed het zelf fout omdat ik ook geen expert ben in de typografie. Mijn punt was dat de orientatie van een glyph een standaard element is in typografie (en daar is de specificatie tenslotte voor). Je gaat ook niet in de specs uitleggen waar een paragraaf voor is, toch?
Enige basiskennis mag verwacht worden van iemand die dit gaat implementeren. Het is een technisch document, geen "For dummies" handleiding.
Zo evident was het dus zeker niet. De info in de ODF spec was zonder meer te summier voor implementatie maar Bolleke heeft me overtuigd dat iemand met kennis van de materie (tekstrotatie) er wel redelijk eenvoudig uit zou zijn gekomen.
Nee - ik heb helder uiteengezet dat de gebruikte termen (die jij niet kende en dus "summier" en "onvolledig" noemt, en die ik ook niet kende maar die ik daarom even heb opgezocht, want dat doe ik als ik een woord of term niet ken) standaardjargon zijn m.b.t. de materie in kwestie - namelijk, typografie. Dat heeft niks met "er uitkomen" te maken, iemand die in deze materie thuis is kent die terminologie gewoon. Net zoals dat je bij de uitleg van een bepaalde functie in een bepaalde programmeertaal niet nog eens hoeft uit te leggen wat een argument en een returnwaarde is - iemand die dat leest is programmeur en weet dat, dat heeft niks met de programmeertaal zelf te maken, laat staan met een "fout in de documentatie".
Overigens was daarbij nog steeds aan de orde dat het nut van de functie door de inperking waardebereik (uit of automatic) onduidelijk is gebleven in die discussie.
Bollek gaf aan dat het waardebereik van glyph-rotation mogelijk in de toekomst kan worden uitgebreid maar dan is het niet duidelijk waarom het item nu al zonder zinvolle waarde in de spec is opgenomen
Alweer "nee": ik heb je daar ook duidelijk uitgelegd dat 0 en auto de enige twee nuttige waardes in een tekstverwerker zijn, namelijk "negeer elke tekstrichting en zet dat ding rechtop" en "neem over wat standaard is voor de huidige tekstrichting". Alle andere waardes zijn eigenlijk alleen nuttig als je zwaar psychedelisch aan het DTP'en bent en daar is een tekstverwerker nou eenmaal niet voor.
Mocht men ODF ooit willen uitbreiden met een DTP sectie om de concurrentie met Adobe e.d. aan te gaan (off-topic: zouden die bestanden dan .odd heten? :)) dan kan dat dus ook makkelijk, maar ik zou werkelijk waar geen enkele zinnige reden kunnen bedenken waarom een normale tekstverwerker dat soort meuk zou moeten ondersteunen. Net zoals een tekstverwerker ook geen complexe berekeningen in tabellen ondersteunt, daar pak je een spreadsheet voor.
Je zit dus weer mijn woorden te verdraaien/bagatelliseren. Of je doet dat bewust en dan ben je heel naar bezig, of je snapt het gewoon echt niet. In het laatste geval kun je daar niks aan doen, maar ga hier dan niet allerlei foutieve informatie lopen verkondigen alsjeblieft.
Met je verhaal over MathML (en deels ook SVG) lijk je wel een punt te hebben, ik zou dat verder moeten uitzoeken (dit even los van het feit dat het meer kritiek op beide genoemde externe standaarden was dan op ODF). Je was best goed bezig maar nu dit weer. Als iets aan het bovenstaande verhaal je niet duidelijk is leg ik dat graag verder uit, maar vraag het dan alsjeblieft gewoon prive aan me in plaats van met oogkleppen op en plein public alsnog te doen alsof je gelijk had.
Het ging ook niet om een melden van een fout in ODF maar over een stuk ODF specificatie met volgens mij onvoldoende informatie om deze functie te kunnen implementeren.
Het was wel duidelijk dat het je daar om te doen was.
De info in de ODF spec was zonder meer te summier voor implementatie maar Bolleke heeft me overtuigd dat iemand met kennis van de materie (tekstrotatie) er wel redelijk eenvoudig uit zou zijn gekomen.
Dan was die tekst dus niet 'zonder meer te summier'.
Maar laten we nog eens teruggaan naar hoe we precies op dit punt kwamen. Op een gegeven moment geef je de volgende oorzaak voor de lengte/vaagheid van OOXML.
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.
In de eerste plaats is het fundamenteel onlogisch dat de lengte van OOXML verzoorzaakt zou worden door de (door jou vermeende) niet implementeerbaarheid van ODF.
Maar waar het mij nu even om gaat. Als je eerst beweert dat het barst van de elementen waarvan volstrekt onduidelijk is wat ze doen of hoe je ze moet implemneteren en dan niet met een beter voorbeeld dan jouw volledig ontkrachte glyph-orientation kan komen, is het dan niet eens tijd je aanvankelijke bewering terug te trekken? Of kom je in de eerste volgende ODF/OOXML weer keihard met de bewering dat de ODF standaard volstrekt onduidelijk is?
Als het werkelijk barst van voorbeelden die volstrekt niet implementeerbaar zijn, was dit dan echt het beste voorbeeld waar je mee tevoorschijn kom komen?
Als je hier gelezen had had je kunnen weten dat ook de password hashing van protected content niet beschreven is maar zo zijn er meer zaken die in ODF niet duidelijk zijn(embedding van externe formaten, spreadsheet formules) en daardoor gewoon niet interoprabele implementaties opleveren.
Het is gewoon op basis van de beperkte ODF specificaties zo goed als onmogelijk om interoperabiliteit te creeren.
En zelfs belangrijkde voorstanders vinden dat:
http://www.oasis-open.org/archives/odf-adoption/200709/msg00032.html
Hier een commentaar van de KOffice Lead developer over interoperabiliteit tussen ODF implementaties (het grote doel achter ODF)
One thing I have always dreamed to be possible is that when I write a doc
in KOffice I can then open it in OOo to use that one feature that's
useful to me and then save it and continue in KOffice without loosing
lots of data.
Its still a dream, of course. Most features are lost on opening and saving
it in OOo, but its a nice goal :)
We hebben het dan wel over een formaat dat al tweeeneenhalf jaar geleden is gestandaardiseert en waarbij zowel Sun/OOo en Koffice ook als twee jaar daarvoor bij de ontwikkeling betrokken waren.
Heeft hij het wel over ODF? Heeft hij het niet over de applicaties? Volgens mij heb je moeite met helder lezen,
Hij zegt nergens dat ODF niet in staat is eenduidig gegevens op te slaan, hij heeft het over een specifiek applicatie probleem in samenhang met ODF en OpenOffice en KOffice. Hij zegt dat OOo de meeste van de besproken Koffice features verliest bij openen en bewaren. Hij zegt dus heel specifieks iets over OpenOffice en KOffice, hij zegt helemaal niets over ODF. Maar ik merk dat jij in deze discussie vaker de standaarden en de applicaties verwisselt. Dat zei Bolleke ook al enkele keren.
Dat is een slordige positie in deze discussie, en bij certificeringstrajecten een doodzonde. Het is simpel: Niet de applicaties worden gecertificeerd, maar de standaard.
(echter, dat jij zomaar in deze email-discussie kunt binnenkijken geeft wel aan hoe alles in openheid plaatsvindt)
Dit is een reactie op niemand specifiek, maar in het algemeen.
Het grote probleem met deze discussie, en de duizenden discussies die naar aanleiding van deze non-gebeurtenis wereldwijd worden gevoerd is dat er geen nieuwe argumenten komen, de posities bekend zijn, de discussies dus, voorspelbare inhoud hebben.
Veel plezier ermee jongens (en een enkel meisje)
Als ze IE met verschillende "render engines" kunnen bouwen, waarom zouden ze dat niet met Office doen?
OOXML is een xml-representatie van de wijze waarop office documenten in het geheugen bewerkt.
ODF sluit daar niet op aan. Deze bestandsopmaak heeft andere features dan OOXML. (op sommige gebieden zal de één uitgebreider zijn, op andere gebieden de ander)
Als Word intern uitsluitend aan zou sluiten bij ODF dan zou het opnenen van oude documenten altijd een conversie (met gegevensverlies) opleveren, net als een export.
De overgangsoplossing is een duale applicatie, waarbij documenten op twee manieren in het geheugen kan zijn gecodeerd. Een beetje hoe IE een "strict" en een "transitional" modus kent.
Microsoft kennende zijn ze hier al aan bezig. Maar ze moeten het rekken totdat het af is.
Wat in het IBM verhaal niet naar buiten komt is dat er nog steeds grote problemen zijn om ODF interoperabel te krijgen en dat bepaalde mythes rondom de kwaliteit van ODF nu ook danig beginnen te vervallen.
Er zaten zeker een flink aantal fouten in de eerste OOXML maar tijdens het standaardisatie proces zijn worden daar de meesste van op gelost en krijg je dat OOXML op steeds meer onderdelen juist ODF ver voorbijsteekt qua informatie voor degenen die de specificatie moeten implementeren.
Een voorbeeldje is te vinden in deze blogpost:
blogs.msdn.com/...rd-hashing.aspx
waarin de verbeterde OOXML paginas met informatie voor password hashing wordt besproken en waar met ingaat op een detail dat nog aanpassing vereist.
Daartegenover de diepgaande volleidge ODF tekst beschrijving over password hashing:
"To avoid saving the password directly into the XML file, only a hash value of the password is stored"
Geen info over hoe er gehashed wordt of met welke encryptiemethodes...
Dat is dus een voorbeeld van de zogenaamd superieure en interoperabele ODF specificatie. Er werd vaak geklaagd over de grootte van de OOXML spec maar als je gewoon alle noodzakelijk info weglaat dan wordt je specificatie daar echt niet beter en meer interoperable van.
Ook is ODF 1.0 al in 2005 gestandaardiseerd door OASIS en zitten we nu in 2008 nog steeds te wachten op bijvoorbeeld spreadsheet formules en presentations tabellen die nog steeds niet door ODF worden ondersteund en is de ODF 1.1 versie waarin bijvoorbeeld verbeteringen zitten voor viuseel gehandicapten nog steeds niet aan ISO doorgegeven. Het lijkt erop dat de ontwikkeling en verbetering van ODF supertraag verloopt. Ze doen nu al langer over de ontbrekende elementen uit de originele standaard dan ze eerder over die gehele standaard hebben gedaan waardoor de vraag rijst of ODF eigenlijk niet gewoon onvoltooid over de muur naar ISO is gegooid.
De reden voor IBM om tegen de OOXML standaardisatie te zijn is dan ook niet gelegen in de technische kwaliteit maar in het feit dat zij met Lotus Notus 8 en Lotus Symphony (=gebaseerd oude OOo versie) twee office producten hebben die volledig gebaseerd zijn op het gebruik van het ODF formaat en dat zij hopen dat overheden ODF verplichten zodat zij deze producten kunnen verkopen.
Daartegenover de diepgaande volleidge ODF tekst beschrijving over password hashing:
Baseline, ik heb je er al eerder op gewezen dat wat jij als "tekortkomingen" van ODF omschrijft vaak slechts tekortkomingen in je eigen kennis/bereidheid tot lezen zijn.
Zo ook hier. Het hash-mechanisme dat door ODF wordt gebruikt is generiek en staat omschreven in 17.3. Hou nou eens op met stukjes uit hun context te lichten en op basis daarvan hard te schreeuwen dat de specificatie onvolledig is. Bij voorbaat dank.
Sorry, 17.3 moest zijn 17.3 en verder, 't is nogal een uitgebreide sectie. Maar om het even samen te vatten voor je: 't is een 20-byte digest van een SHA1 hash. Andere hash-algoritmes worden op dit moment niet ondersteund, al omschrijft 17.7.4 het mechanisme om dat evt. in de toekomst uit te breiden.
On-topic, en voor je daarover begint: soit, MD5 kan ik me nog iets bij voorstellen, maar waarom een redelijk afgeserveerd algoritme als MD2 zou moeten worden ondersteund is mij een raadsel.
Oh nee, wacht: dat is vast voor backwards compatibility...
Volgens mij stond er in paragraaf 17.3 de encryptie methode om de hele file te encrypten op basis van een password hash. Hoofdstuk 17 is dan ook het beschrijven van het file packages. Dat betreft dus slechts de file encryptie (voor zover ik dat uit de specs kan opmaken).
De teksten waaraan ik refereerde is bijvoorbeeld voor het protecten van van sections en tables en die sections hoeven dan zelf helemaal niet encrypted te zijn. Het zijn gewoon delen van het document die bijvoorbeeld read only gemaakt zijn.
Er staat bij de info over de password hashing van secties en tables nergens ook maar een een verwijzing dat de in paragraaf 17.13 omschreven encryptie methode voor het encrypten van de hele file ook moet worden toegepast op password hashes. Het is dus helemaal niet logisch om die koppeling zelf dan maar te leggen.
Ik ben het met je eens dat het er duidelijker had kunnen staan, maar ik lees het volgende in 17.7.4:
Checksum Type
The manifest:checksum-type attribute specifies the name of digest algorithm that can be used to check password correctness. Currently, the only supported digest algorithm is SHA1.
Ja ,dat is het password opgeslagen in het manifest file waar je dus alle info vind om files in je package te decrypten. Het is niet evident dat deze info niet alleen opgaat voor encrypted files maar ook voor de hashing van password protected documentdelen die niet encrypted zijn.
Ja ,dat is het password opgeslagen in het manifest file waar je dus alle info vind om files in je package te decrypten. Het is niet evident dat deze info niet alleen opgaat voor encrypted files maar ook voor de hashing van password protected documentdelen die niet encrypted zijn.
Maar lieve Baseline, het is toch logisch dat deze secties bij elkaar staan. Immers, wat heb je aan een "password-protected" bestand in plain-text XML? Beveiliging en encryptie zullen altijd hand in hand moeten gaan, anders heeft het geen enkele zin. Maar ik ben benieuwd naar de geniale oplossing die OOXML hiervoor heeft, daar werkt het kennelijk anders, anders zou je deze denkfout niet gemaakt hebben lijkt me.
Beveiliging en encryptie zullen altijd hand in hand moeten gaan, anders heeft het geen enkele zin.
Nu heb je denk ik de essentie niet meer door want er is een groot verschil tussen protected en encrypted content.
De proctected content is bedoeld om content bijvoorbeeld read-only te maken en zo onbedoelde wijzigingen te voorkomen maar niet om de data te verbergen. Zowel ODF als OOXML bevatten methodes om content delen zoals tabellen te protecten met een wachtwoord en die content is dan dus niet encrypted.
Jij verwijst naar een stuk over encryptie van content en relateert dan de daarin genoemde beveiligingsmethode dan ook maar aan in de spec genoemde protected, maar niet encrypted, content terwijl de spec dat zelf dus niet doet. Dat is niet logisch en bovendien beschrijft de encryptiemethode in het manifest een tag om toekomstig verschillende algoritmes te kunnen gebruiken ( <attribute name="manifest:algorithm-name"> ) en de protected password hashing methode bevat een dergelijk methode niet. Het zijn dus ook zaken die verschillende qua functionaliteit.
Nu heb je denk ik de essentie niet meer door want er is een groot verschil tussen protected en encrypted content.
Natuurlijk niet. Laat ik het anders uitleggen.
Zowel ODF als OOXML zijn XML-based formaten. Dat betekent dat er in plain-text informatie instaat, bijvoorbeeld:
<document>
<body>lorem ipsum dolor sic amet</body>
</document>
Elke willekeurige teksteditor kan dit inlezen en wijzigen.
Nu wil ik dit document beveiligen (b.v. tegen schrijven). Ik zet er een password op:
<document>
<password>qwerty</password>
<body>lorem ipsum dolor sic amet</body>
</document>
Heeft dit zin? Neen, want het is nog steeds plain-text die door elke willekeurige teksteditor te wijzigen is. Dus neem ik het password als seed voor encryptie, en krijg ik bijvoorbeeld
<document>
<password>qwerty</password>
<body>FGE$%U$%^&GE$&*OHIGHF%GHN^*GJU%EY^R*KIG^E</body>
</document>
Ik kan nu nog steeds de content wijzigen, maar de kans dat daar iets zinnigs uitkomt is 0 tenzij ik het password gebruik om het eerst te ontsleutelen. Dit was een zwaar gesimplificeerd voorbeeld (b.v. ODF encrypt alle deelbestanden op een meta-bestand na in z'n geheel) maar het geeft wel de essentie weer.
Dus nogmaals, als het onder OOXML anders werkt ben ik heel benieuwd hoe, jij kunt me dat vast wel vertellen. Maar encryptie is dunkt me een voorwaarde voor beveiliging, anders is het namelijk geen beveiliging.
(.DOC bestanden met een password zijn binair ook anders dan zonder. Hoop ik toch van harte.)
<te open deur>Het zou me ook niks verbazen als OOXML de beveiliging verder niet afdwingt, 't is tenslotte van Microsoft</te open deur>
Ik neem voorgaande deels terug, ook in ODF staat het volgende:
A section can be protected, which means that a user can not edit the section. The text:protected attribute indicates whether or not a section is protected. The user interface must enforce the protection attribute if it is enabled.
Dat vind ik dan ook niet slim. Lijkt me niet iets handigs om te gebruiken.
A user can use the user interface to reset the protection flag, unless the section is further protected by a password. In this case, the user must know the password in order to reset the protection flag.
Ik snap wel *dat* dit erin zit, maar logisch is het niet in mijn ogen. Voorkomt wel "per ongeluk" wijzigen, maar meer ook niet.
Ah, dat bevestigt de manual van OOo ook duidelijk:
This protection is not intended to be a secure protection. It is just a switch to protect the section against accidential changes.
Blijft dus over de vraag welk algoritme ODF gebruikt voor die passwords. SHA1 lijkt voor de hand te liggen, maar een snelle test doet vermoeden dat er nog een andere salt doorheen gaat... iemand meer info hierover?
Probeer eens de ODF spec ;-)
(ok, wat flauw misschien maar het is ook best wel grappig dat je nu eigenlijk zelf mijn eerste commentaar over de onvolledige ODF op deze manier bevestigd)
Probeer eens de ODF spec ;-)
Nou ja, ik ga er vooralsnog vanuit dat dat ook een SHA1 is. Maar ik geef je ook gewoon gelijk dat dit er niet duidelijk of goed in staat. Nobody's perfect.
Ik gok dat de bedoeling is dat je ofwel zo'n stuurgeval toevoegt als het ooit niet-sha1 wordt, of dat je per document maar 1 soort kunt opgeven. Maar ik heb het nu te druk om specificaties uit te gaan pluizen ;-)
Had jij nog nagekeken hoe dat in OOXML zat? (Heb ik het nl. al helemaal te druk voor ;-))
Wat ik me net bedenk: is het niet bewust ongespecificeerd omdat het iets van de applicatie is, niet van de specificatie? De applicatie moet het immers ook afdwingen. Zomaar een gedachte.
Ook applicaties anders dan de applicatie die het de protect password aan een document heeft toegevoegd moeten de protectie ook afdwingen.
Bovendien kan een implementatie niet aan de protectie password zien door welke implementatie deze is toegevoegd. Het enige wat een applicatie kan constateren is of een door een gebruiker ingevoerd password om iets te unlocken hoort bij de in het document opgeslagen hash.
Ook applicaties anders dan de applicatie die het de protect password aan een document heeft toegevoegd moeten de protectie ook afdwingen.
Dat kan ook wel, ze kunnen hem dan alleen niet opheffen op basis van het password ;) Het is sowieso een hele rare functie IMHO.
Bovendien kan een implementatie niet aan de protectie password zien door welke implementatie deze is toegevoegd. Het enige wat een applicatie kan constateren is of een door een gebruiker ingevoerd password om iets te unlocken hoort bij de in het document opgeslagen hash.
Precies, dus dat lost zich vanzelf op. Maar goed, ik ben het met je eens dat het een wat onduidelijke en vooral overbodige feature is. Ik zou 'm zelf weggelaten hebben, maar ik kan me voorstellen dat ze hem er toch ingestopt hebben omdat mensen hem zijn gaan verwachten (omdat MS Office het ook heeft?).
Ik ben nog ff aan het stoeien met die ODF-passwords, het lijkt erop dat ik een foutieve of in elk geval afwijkende SHA1-implementatie had gepakt voor mijn test.
Precies, dus dat lost zich vanzelf op
Gek ik krijg dan juist het idee dat een applicatie dus nooit meer iets zal unlocken als het door een andere applicatie(versie) met een onbekende hash methode is beveiligd ook al weet je het password nog wel.
Gek ik krijg dan juist het idee dat een applicatie dus nooit meer iets zal unlocken als het door een andere applicatie(versie) met een onbekende hash methode is beveiligd ook al weet je het password nog wel.
Het unlocken is het probleem niet; het is immers gewoon plain-text. De applicatie kan kiezen zich er wel of niet iets aan gelegen te laten liggen. Daarom is het ook zo'n rare feature. Ik vermoed dan ook sterk dat de methode van opslaan gewoon applicatie-specifiek is en dat het er verder niet zoveel toe doet. Een zelfde soort voorbeeld is er bij het password veld voor communicatie met externe apps; dit is ook applicatie-specifiek. En dat is ook logisch, ODF kan voor een externe applicatie niet besluiten hoe ze hun passwords moeten hashen.
Storm in een glas water dus over een functie die waarschijnlijk nauwelijks iemand gebruikt (ik moest in elk geval spitten in de manual om te vinden hoe ik het op paragraaf-niveau aan kon zetten) en die los daarvan ook nauwelijks ter zake doet, en waarvan het "probleem" makkelijk te omzeilen is.
Maar als ik je daar gelukkig mee maak wil ik best van het weekend even in de source van OOo gaan spitten om te kijken wat zij precies doen daar. Gezien de lengte van het gehashte password gok ik dat het ook gewoon een SHA1 is, net als bij de encryptie. Maar de standaard schrijft dat dus niet voor, omdat de implementatie ook applicatie-specifiek is. Dus vanuit theoretisch oogpunt valt daar best wel wat voor te zeggen, al geldt dat voor jouw tegenwerpingen net zo goed. Het lijkt erop dat er hier gewoon een bepaalde keuze is gemaakt.
On-topic, en voor je daarover begint: soit, MD5 kan ik me nog iets bij voorstellen, maar waarom een redelijk afgeserveerd algoritme als MD2 zou moeten worden ondersteund is mij een raadsel.
Oh nee, wacht: dat is vast voor backwards compatibility...
Leuk dat je dat opnoemt. Het geeft een fundamenteel verschil aan in filosofie tussen Microsoft en OASIS.
Door het ondersteunen van eerdere password hashes kun je een document met protected content onderdelen (bijvoorbeeld een protected table) converteren en de betreffende delen protected laten. Als je een dergelijk document naar ODF converteert dan moet je de protectie droppen tenzij je zeker weer dat de hashing methode overeenkomt.
Ook leuk daarbij: Je noemde eerder al dat het manifest deel van de files beschreven in hoofddstuk 17 de mogelijkheid biedt om het encryptie algoritme per encrypted file te specificeren zodat je dus in de toekomst de password hashing mogelijkheden kan uitbreiden. Bij de password hashes voor protected document delen staan geen mogelijk algoritmes. Dus je kunt helemaal niet bepalen met welk algoritme dergelijke password zijn gehashed.
Het probleem met OOXML is de ondersteuning van allerlei binaire data in de XML. Dat zal straks zeker gebruikt/misbruikt worden om Office een voorsprong te geven op de concurrentie. En als dat 10x grotere document nou beschreef hoe die binaire formats inelkaar steken, maar nee hoor.
Het probleem met OOXML is de ondersteuning van allerlei binaire data in de XML.
Wat een onzin. Er is helemaal geen probleem met de ondersteuning van binaire data in de XML. Sterker nog, ODF is veel meer ingericht om binaire data in de XML te stoppen omdat ODF ook in een single XML file kan worden gebruikt. Daarom zijn bijvoorbeeld alle externe file-elementen zoals plaatjes, geluid of video in ODF als base64encoded data rechtstreeks in de XML te stoppen.
Jullie zeggen hetzelfde:
R:- Het probleem van OOXML is dat het binaire data ondersteunt
b:- Wat een onzin, OOXML ondersteunt binaire data wel!
Ik zie er geen groot voordeel in om binaire data mee te coderen in xml.
Wat is er het nadeel van om dit in een apart document te doen?
Nee, ik zeg dat het ODF is die uitgebreide binaire ondersteuning in XML biedt. Het is dus onzin omdat als verwijt te leggen bij het OOXML formaat terwijl juist ODF overal al base64encoded data in de XML ondersteunt.
Maar misschien wist je dat nog niet. ODF supporters noemen namelijk meestal niet op dat ODF ook binaire data ondersteunt en eigenlijk nog veel ruimer dan OOXML dat doet (eigenlijk zoals de oude Office 2003 XML files dat deden).
Ik begrijp dat de reden voor MS om een eigen open standaard te willen daarmee steeds minder belangrijk wordt? :-)
Er zijn nog zat redenen waarom ODF niet geschikt is voor Microsofts gebruik in met name MS Office. Een paar voorbeeldjes
* ODF bevat geen performance optimalisaties voor bijvoorbeeld spreadsheets
* ODF biedt geen backwards compatibliteit met bestaande documenten (zoals bijvoorbeeld te zien bovenstaand password hashing voorbeeldje)
* ODF heeft veel beperktere grafische feature ondersteuning
* ODF heeft geen met de office functionaliteit intergreerbare Math ondersteuning zoals OOXML
* ODF heeft geen custom data features waarmee organisaties eigen data kunnen integreren in Office documenten
* ODF gebruikt een mindere efficiente packaging structuur
* ODF is afhankelijk gemaakt van een aantal w3c webstandaarden. Dat heeft nadelen omdat deze webstandaarden niet gemaakt zijn voor muteerbare bestanden en daar geen goede functionliteit voor bieden en ook op sommige andere punten functionliteit te kort komen. Daardoor heeft ODf bijvoorbeeld al eigen drawing definities voor uit SVG geleende objecten en creert het een SVG dialect dat niet compatible is met de SVG standaard.
En voor MS zou alleen het backwards compatibiliteits issue al voldoende zijn om te kiezen voor hun klanten en een formaat aan te bieden dat deze compatibiliteit wel biedt.
En Microsofts OOXML bevat natuurlijk wel performance optimalisaties??
Wat een onzin een bestand heeft dat niet nodig dat moet een applicatie oplossen. Een bestand is puur om data bruikbaar en gestructureerd in te bewaren.
Datzelfde geldt natuurlijk ook voor mutaties... En waarom zou de ene XML structuur beter ingericht zijn op wijzigingen dan de andere??? XML structuren zijn per definitie lastig te bewerken, zeker als je de XML structuren gebruikt om documenten in op te slaan (of spreadsheets of presentaties).
En voor wat betreft compatibiliteit is bij Microsoft geen enkele vorm van compatibiliteit gegarandeerd. Als het ze niet uitkomt dan vebreken ze die gewoon. Kijk maar naar de overstap van IE6 naar IE7. Kijk maar naar Office2000 naar Office2003 en probeer maar eens wat complexere documenten te converteren. Of ben je dat alweer vergeten.
Wat een onzin een bestand heeft dat niet nodig dat moet een applicatie oplossen
Dat is dus gewoon onjuist.
Het is bijvoorbeeld vergelijkbaar met een tabel in een database met of zonder index. Je kunt dezelfde gegevens eruit halen maar een tabel met een index kan veel sneller toegang bieden tot die gegevens. Dan is het argument ook niet dat het DBMS dat maar moet oplossen.
baseline, wat een prachtig voorbeeld! Serieus, dit is een hele goede analogie.
Dat is dus gewoon onjuist.
Het is bijvoorbeeld vergelijkbaar met een tabel in een database met of zonder index. Je kunt dezelfde gegevens eruit halen maar een tabel met een index kan veel sneller toegang bieden tot die gegevens. Dan is het argument ook niet dat het DBMS dat maar moet oplossen.
DAT is dus gewoon onjuist. SQL bepaalt niks over indices, elke database heeft daar zijn eigen mechanisme voor(*). Als je de SQL van een database dumpt staat daar alleen bij voor welke velden de indices gelden; hoe je dat in een andere database implementeert moet je zelf weten, de indextabel wordt niet meegedumpt ofzo.
Dus ja, de applicatie lost dat op, niet de "standaard" (niet dat ik zo snel ook maar 1 database kan bedenken die zich puur aan de SQL standaard houdt, maar dat terzijde) en al zeker niet de plain-text representatie van de data. Als ik een geniale nieuwe manier van indexeren bedenk waardoor mijn database 10x sneller wordt, zit ik dan vast aan een "index standaard"? Nee, natuurlijk niet. Maakt het uit als ik mijn data porteer naar een andere database? Nee, natuurlijk niet, die gebruikt gewoon zijn eigen index.
(*) ja, er zijn natuurlijk best practices
Als je de SQL van een database dumpt staat daar alleen bij voor welke velden de indices gelden; hoe je dat in een andere database implementeert moet je zelf weten, de indextabel wordt niet meegedumpt ofzo.
Jouw analogie is waarbij je een tabel verhuis naar een ander soort database en lijkt meer de analogie van een conversie naar een ander formaat bestand. Een zeldzame handeling.
Mijn analogie gaat over normaal gebruik van bestanden en tabellen, het normale gebruik van een bestand vergeleken met het gebruik van een tabel.
Een index wordt bij een conversie naar een andere database misschien niet opgeslagen maar natuurlijk wel gewoon bij normaal gebruik van een tabel en niet bij elke sessie opnieuw opgebouwd terwijl je bijvoorbeeld bij het openen van een ODF spreadsheet ook alles opnieuw moet opbouwe.
Evident in ieder geval is dat je met gebruik van OOXML over performance verbeteringen beschikt die je in ODF niet hebt. Je kunt wel hoog en laag springen dat je vind dat het niet in een formaat thuis hoort maar effectief is het resultaat dat zeker voor grote spreadsheets met veel data je doorgebruik van OOXML een betere performance kan halen.
Jij vind het onzin maar Microsoft vind spreadsheet performance blijkbaar wel relevant.
Echter jou houding bevestigt juist eigenlijk precies dat Microsoft er dus juist heel goed er aan doet om hun Office XML formaat vrij te geven en te laten standaardiseren. Een formaat dat deze zaken wel biedt terwijl ODF aanhangers deze zaken dus niet belangrijk vinden en niet in hun formaat zullen opnemen. Er is dus duidelijk een verschil in de manier waarop verschillende partijen een formaat willen gebruiken en dus ook een heel rechtmatige zaak om daar voor meerdere formaten te gebruiken en niet allemaal achter 1 formaatvisie aan te lopen.
Uiteindelijk kunnen de gebruikers van ODF en OOXML producten kiezen en als ze grote spreadsheets gebruiken dan is de kans groot dat een op OOXML gebaseerd product daar een voordeel heeft.
Ik heb een keer Excel als database (mis)(ge)bruikt. Het koste best veel moeite om de data op de gewenste manier erin te krijgen. Ze moesten voorbewerkt worden, etc.
Uiteindelijk was het gereed en ik had een spreadsheet van een paar honderd MB. Toen ik hem de volgende dag wilde openen crashte Excel, en dat iedere keer opnieuw.
Sindsdien weet ik het, een spreadsheet programma is niet geschikt of bedoeld voor grote dataopslag. Dat is geklungel. Dat is niet professioneel. Er is geen manier om ook maar iets van de data te redden als er wat misgaat, je kunt niet de data deels openen, zoals dat in een professionele database wel kan.
En er zijn weinig berekeningen denkbaar op grote hoeveelheden data die niet in een geavanceerde SQL-database kunnen worden gedaan.
Dat is net zoiets als een boek schrijven in een MS-Word-document, als er ergens een bitje omvalt, kan je, met een beetje pech, dag zeggen tegen je boek. Er is menig student dit overkomen met zijn scriptie. Zelf heb ik ooit uit een Word document de platte tekst moeten destilleren, voor een schrijver.
Dit was twee seconden werk dankzij het onovertroffen programmaatje "strings", dat in Linux standaard beschikbaar is. Maar de opmaak, en voetnoten, etc, dat is verloren. Maar goed, nu ben ik een min of meer computer deskundige, en beschik ik over tools waar normale computer-gebruikers niet over beschikken.
Er zijn ook mensen die drukwerk opmaken in Word, maar ook dat is niet erg professioneel, een ander beeldschermformaat/resolutie kan de layout al verstoren.
Zo zijn er veel dingen waarvoor Office-applicaties niet zijn bedoeld, en ook niet speciaal geschikt voor zijn. Als dit binnen bedrijven toch gebeurt is dat inefficient, geklungel en kan tot ongelukken leiden, en dat gebeurt dan ook regelmatig (Murphy ligt altijd op de loer), en dan zijn de kosten van een enkel ongeluk regelmatig veel hoger dan een gespecialiseerde applicatie gekost zou hebben
Dus je moet je afvragen of dit soort geklungel in Office-ISO standaarden ondersteund moet worden. Je gebruikt (voorbeeld) de ISO standaard "inch" ook niet om de afstand naar een sterrenstelsel uit te drukken, het kan wel, maar er is bij de definitie geen rekening gehouden met een dergelijk gebruik, end at is maar goed ook. Bij een ISO standaard voor tractor-banden is ook geen rekening gehouden met snelheden van 120 km/uur op de autoweg.
Ik heb hier bijvoorbeeld gewoon excel spreadheets die met ODBC gekoppeld zijn aan SQL databases en waar de data telkens ingequeried kan worden en dan op talloze wijzen worden bewerkt voor statische doeleinden met trends en grafieken. (met CSV files inlezen van de data kan trouwens ook)
Het zou ons kapitalen kosten om dat in bijvoorbeeld Oracle te laten bouwen of kapitalen in licentie en ondersteuning voor geavanceerdere datamining tools.
Een excel sheet is niet nuttig als opslag en beheer tool van data vergeleken maar een database maar wel nuttig voor het uitvoeren van zaken statistische bewerkingen op data en eenvoudige incidentele datamining.
Dat is ook een heel ander gebruik. Maar zonder nu bedrijven te moeten vertellen hoe ze hun data moeten beheren, en op specifieke situaties te moeten ingaan, is het goed om te beseffen dat je bulk data niet in meerdere kopieën moet onderhouden. Ook dit is een directe uitnodiging aan Murphy.
Dus als je in Excel bepaalde berekeningen wil toepassen op bulkdata, dan is het goed om eerst zoveel mogelijk bulk niet in je desktop in te laden, maar middels views/stored procedures op de SQL-databases te bewerken, en daarna de resultaten in je Excelletje te laden, inderdaad via een live koppeling, bijvoorbeeld ODBC (hoewel dat wel erg verouderd is).
Op deze wijze gebruik je Excel niet voor grote data-opslag, terwijl je wel rekenkundige bewerkingen kunt doen op grote hoeveelheden data. Maar vervlogens moet je neit deze grote hoeveelheden data willen opslaan in ODF of OOXML, want dan ga je juist kopieën van dat maken, met alle risico's/nadelen van dien.
De risico's/nadelen zijn corruptie, overbelasting van desktop-systeem/overbelasting van netwerk-omgeving nabij datacluster (cruciaal gebied), uit sync raken van data (en resultaat berekening), etc, etc.
Voordat je het weet ben je met een personen-auto aan het ploegen, het kan wel, als de grond niet te vet is, met sommige merken, maar een tractor werkt beter.
Een index wordt bij een conversie naar een andere database misschien niet opgeslagen maar natuurlijk wel gewoon bij normaal gebruik van een tabel en niet bij elke sessie opnieuw opgebouwd terwijl je bijvoorbeeld bij het openen van een ODF spreadsheet ook alles opnieuw moet opbouwe.
True, maar er is dan ook niemand die jou verbiedt die index ergens op te slaan in je applicatie. Het punt is dat-ie niet in de specificatie thuishoort, net zoals een database-index niet in SQL thuishoort. Op die manier kun je je bestand zonder problemen in een andere applicatie (desnoods een teksteditor) openen zonder problemen. Of en hoe deze andere applicatie dan wil indexeren moet-ie lekker zelf weten.
Ik snap dat het misschien een wat lastig uit te leggen principieel theoretisch punt is, maar applicatie-logica hoort niet thuis in een formaat. Als je b.v. in de specs van HTML kijkt staat daar bij H1
There are six levels of headings in HTML with H1 as the most important and H6 as the least. Visual browsers usually render more important headings in larger fonts than less important ones.
Er staat niet "tekst tussen H1 moet 50 pixels fontgrootte hebben". Dat is user-agent-specifiek.
Een iets ingewikkelder voorbeeld uit dezelfde hoek die wel beter aansluit bij jouw voorbeeld: van een HTML document wordt een DOM-tree gebouwd in het geheugen van browsers. De HTML zelf wordt gecached op schijf zodat een volgende load bij ongewijzigde content sneller verloopt. Dit schrijft de standaard niet voor; als je dat als browserbakker niet wilt doe je 't lekker niet.
Ik kan me ook zo voorstellen dat het performance winst oplevert als je de geparste tree van de DOM erbij opslaat (zou best kunnen dat er browsers zijn die dat ook al doen, dat weet ik niet). Da's dan een soort index. Maar die staat los van je bron, te weten het HTML bestand. Als je dat met een andere browser opent gaat die er weer anders mee om, maar het blijft wel portabel. Ook hoef je bij het wijzigen van je HTML niet zelf apart nog een DOM-tree aan te passen ergens.
Jij noemt de gelinktheid van data tussen verschillende XML-bestanden binnen hetzelfde office-document een voordeel; ik noem dat een nadeel en zeg dat de te behalen performancewinst (die er uiteraard is) door de applicatie geregeld en evt. gecached moet worden, niet in het formaat zelf. Dat is nergens zo, waarom zou dat voor officedocumenten anders moeten zijn?
Voor wat betreft je andere voorbeelden op dit gebied: als je een plaatje vervangt vervang je het plaatje, niet de interne naam waarnaar verwezen wordt ;) En links, tja, dat is gewoon platte tekst. Ik vind het heel eng als een applicatie gaat bepalen welke links ik waarmee bedoel. En voor globaal vervangen heb je zoiets als search & replace. Een tekstdocument is geen database; als je dat wil moet je je data in een (openbaring!) database stoppen, dan kun je normaliseren. In een tekstdocument heeft dat geen enkele plaats.
Ik vermaak me hier trouwens wel mee, want ik leer er zelf dagelijks meer over ODF door :-) En over OOXML, ik hoor steeds meer zaken die me er niet van aanstaan ;-) Misschien moeten jij en ik samen een blogje beginnen waar we elkaar dagelijks van repliek dienen in een open brief? Trekt vast veel bezoekers, wat adverteerders erbij en we hebben een leuk hobbyprojectje ;-)
Jouw analogie is waarbij je een tabel verhuis naar een ander soort database en lijkt meer de analogie van een conversie naar een ander formaat bestand. Een zeldzame handeling.
Dat is noui juist de bedoeling van een open ISO Office XML formaat.
Interoperabiliteit moet voorop staan, bestanden moeten onafhankelijk van een bepaalde venodr/versie/applicatie/etc bruikbaar zijn.
het is geen zeldzame handeling, het is het doel!!!
Interoperabiliteit moet voorop staan, bestanden moeten onafhankelijk van een bepaalde venodr/versie/applicatie/etc bruikbaar zijn.
Precies en de ODF specificatie blijkt nu na tweeeneenhalf jaar nog steeds onvoldoende compleet om te zorgen voor de die gewilde interoperabiliteit.
Zo kun je bijvoorbeeld OOXML bestanden dat nog maar een jaar geleden is gestandaardiseerd in Ecma zelfs al openen in verschillenmde Office programmas van verschillende leveranciers op de mobile platformen Symbian, Palm OS , Windows Mobile en IPhone.
ODF bestanden nog op geen van deze platforms.
Precies en de ODF specificatie blijkt nu na tweeeneenhalf jaar nog steeds onvoldoende compleet om te zorgen voor de die gewilde interoperabiliteit.
Het is bijzonder knap dat jij uit die dertig woorden zoveel oorzaak en gevolg kunt afleiden. Zelf is Thomas Zander er niet meer op teruggekomen.
Jij weet dus zeker dat er geen sprake was van een gewone bug?
Dit is werkelijk spijkers op laag water niveau.
Zullenw e nu weer gewoon op basis van argumenten discussieren, want nu ben je aantoonbaar het spoor bijster, zoveel gewicht hangen aan een emailtje van vijf regeltjes, zonder enige precieze specificatie, waar de schrijver zelf niet meer op terug komt........
ODF bestanden nog op geen van deze platforms.
Het heeeft niet mijn hoogste prioriteit om een office applicatie op mijn telefoon te openen, maar ODSF kan wel geopend worden op Linux, meerdere aps, Windows, alle versies, meerdere apps, Apple, FreeBSD.
ik ben ervan overtuigd dat de mobile phone zeker komt. Microsoft heeft een ODF converter, werkt die niet op Windows Mobile dan? Tja, je hebt gelijk ODF heeft nog geen mobile phone ondersteuning, voor zover ik weet.
Tja, je hebt gelijk ODF heeft nog geen mobile phone ondersteuning, voor zover ik weet.
...maar dat is natuurlijk niet omdat een telefoon integraal niet in staat zou zijn ODF te snappen om wat voor reden dan ook. Dat er wel OOXML ondersteuningen voor zijn al is dus een typisch voorbeeld van MS dat zijn gewicht in de strijd gooit en probeert een nieuwe de facto standaard te lanceren. Dit mag dus nooit als argument tellen; we moeten het alleen over kwaliteit hebben.
Als ik werkelijk zou geloven dat OOXML de betere van de twee formaten was dan zou ik er vol achter gaan staan. Maar ik geloof dat niet, het is niet in de geest van een XML-based formaat en laat teveel ruimte voor MS om haar eigen applicatie voorrang te geven. Dat ODF wel of niet perfect is doet in het geheel niet terzake - OOXML lijkt me een verdomd slechte keuze.
Kijk, dit is tenminste een iets concreter lijstje dan de vage kreten. Laat ons het even doornemen... (mr.m deed al een voorzetje):
* ODF bevat geen performance optimalisaties voor bijvoorbeeld spreadsheets
Ik heb je al 1000x uitgelegd dat dat in een applicatie hoort, niet in het formaat. Ik maak als programmeur zelf wel uit hoe ik optimaliseer, want dat speelt alleen binnen de applicatie. Voor de data in het formaat boeit dat geen sikkepit - sterker nog, het is hoogst irritant voor mij als programmeur (zie de calcChain discussie) omdat er allerlei logica wordt afgedwongen.
* ODF biedt geen backwards compatibliteit met bestaande documenten (zoals bijvoorbeeld te zien bovenstaand password hashing voorbeeldje)
Vooropgesteld dat ik geen idee heb wat voor hashes oude MS-documenten allemaal gebruiken: het is een nieuw formaat, het is ook niet gemaakt om backwards-compatible te zijn. Voor oude documenten heb je het oude formaat; nieuwe sla je op in het nieuwe. MS Office blijft toch nog jarenlang(*) het oude formaat ondersteunen, dus er is geen enkele reden dat ze voor nieuwe documenten niet een veiliger hash kunnen gaan gebruiken. Ook dit argument gaat dus niet op als zijnde "reden om het niet te gebruiken".
Voorbeeld:
[open document]
"Oei, dit is een password-beveiligd oud MS-Office bestand! Geef uw password."
[geef wachtwoord]
[deze versie gebruikt MD2, hash en check > klopt]
[document wordt geopend]
[sla document op als ODF]
[wachtwoord wordt gelijk omgezet naar MD5]
Alleen voor automatische conversie is het minder handig, maar ja, je kunt je ook afvragen of het de bedoeling is dat beveiligde documenten automatisch geconverteerd worden - ze zijn niet voor niks beveiligd tenslotte.
Los daarvan vind ik het wel vreemd dat de standaard alleen SHA1 hashes ondersteunt, terwijl dat natuurlijk heel makkelijk een willekeurig algoritme kan zijn (de definitie zit er al in, zelfs). Dus dat kan zeker beter (tenzij ze daar een heel erg goede reden voor hadden die ik nu over het hoofd zie), maar is geen argument voor "kan niet".
* ODF heeft veel beperktere grafische feature ondersteuning
Concrete voorbeelden, graag, op welke punten OOXML meer grafische ondersteuning zou bieden dan ODF. Loze kreten hebben we niks aan. Tja, je hebt kritiek dus die zul je moeten onderbouwen...
* ODF heeft geen met de office functionaliteit intergreerbare Math ondersteuning zoals OOXML
Eh... ODF ondersteunt gewoon MathML. Dus graag iets duidelijker aangeven wat je bedoelt, want op het eerste gezicht is verifieerbaar onwaar wat je zegt.
* ODF heeft geen custom data features waarmee organisaties eigen data kunnen integreren in Office documenten
Misschien begrijp ik je niet goed, maar waarom zou je custom data velden willen? Je hebt net een hele spec waar de XML van gedefineerd is - als je iets anders wilt moet je een andere spec gebruiken of gewoon een custom XML bestand. Voor het praten met externe data zijn er pilot tables.
Maar nogmaals, misschien dat ik deze niet goed begrijp? Kun je voorbeelden geven van waar OOXML dit wel kan? Hoe zou dat trouwens een probleem zijn met het oog op backwards compatibiliteit, de oude MS Office had dit toch ook al niet? Dat zou betekenen dat je een nieuwe feature aangrijpt om aan te tonen dat men destijds niet meekon met ODF, da's een cirkelredenering.
* ODF gebruikt een mindere efficiente packaging structuur
Ik dacht dat ze allebei gewoon ZIP gebruikten. Los daarvan, lekker boeien, dat is natuurlijk geen reden waarom MS Office er niet mee om zou kunnen gaan - hoogstens iets dat je liever beter had gezien.
Zodra ik ergens een bak met de nieuwste Office vind zal ik dat trouwens eens testen.
* ODF is afhankelijk gemaakt van een aantal w3c webstandaarden. Dat heeft nadelen omdat deze webstandaarden niet gemaakt zijn voor muteerbare bestanden en daar geen goede functionliteit voor bieden en ook op sommige andere punten functionliteit te kort komen. Daardoor heeft ODf bijvoorbeeld al eigen drawing definities voor uit SVG geleende objecten en creert het een SVG dialect dat niet compatible is met de SVG standaard.
Zoals Mr.m al opmerkte: XML is sowieso niet gemaakt voor muteerbare bestanden. Het hergebruiken van bepaalde standaarden is juist handig omdat het de learning-curve bekort en de interoperabiliteit vergroot. Daarnaast is er niks mis met het extenden van een bestaande standaard binnen een andere context, mits duidelijk gedocumenteerd (en dat is het).(**) De ODF-specifieke attributen zullen door een stand-alone SVG-parser namelijk genegeerd worden (of zelfs begrepen omdat ze het juiste schema erbij zoeken), of kunnen makkelijk gestript worden (het zijn er ook maar een handvol, niet doen alsof ze SVG compleet stuk maken svp).
Ook dit lijkt me trouwens geen reden waarom Office geen ODF zou kunnen ondersteunen.
En voor MS zou alleen het backwards compatibiliteits issue al voldoende zijn om te kiezen voor hun klanten en een formaat aan te bieden dat deze compatibiliteit wel biedt.
Het enige niet-backwards-compatible argument tot nu toe zijn de password hashes waarvan ik ueberhaupt niet weet hoe de oude binaire formaten dat deden. Daarnaast heb ik al aangetoond dat dat helemaal geen issue is, het gaat namelijk om iets dat in een ander formaat staat en makkelijk omgezet kan worden als je daar toch al mee bezig bent. Als je dat niet wilt maar .doc wilt blijven gebruiken is er ook niemand die je tegenhoudt en is het sowieso geen punt. Kortom, je roept om het hardst dat ODF niet backwards compatible is met de binaire MS Office formaten terwijl dat nergens blijkt uit je argumenten. Bij "niet backwards-compatible" denk ik aan "MS Office had ook tekstdocumenten, en ODF ondersteunt alleen spreadsheets". DAT zou een voorbeeld zijn. Volgens jouw redenering zijn zowel ODF als OOXML niet 100% backwards compatible omdat ze niet binair maar plain-text zijn.
Sorry, ik was mijn voetnoten vergeten...
(*) dat zouden ze althans jarenlang moeten blijven doen als het ze inderdaad om hun klanten gaat.
(**) een echte extensie is iets anders dan een aanpassing. Een extensie is "naast left en right ondersteunt SVG in ODF ook middle bij dit attribuut; dit heeft in pure SVG echter geen effect omdat het alleen van invloed is op de eromheen lopende tekst en dat speelt in SVG niet". De "Microsoft-way" zou zijn "bij ons kun je in plaats van left en right ook leftAlign en rightAlign gebruiken, en we hebben ook leftFloat en rightFloat. 'left' en 'right' los zijn ambigue dus die herkent ons pakket niet."
Zie je het verschil? De eerste heeft een duidelijk gespecificeerde extra waarde omdat het in een context wordt gebruikt waar het niet voor ontworpen is en waar het gedrag anders ongedefineerd zou zijn, maar die buiten die context geen effect heeft. De tweede breekt bewust de bestaande regels door iets nieuws te bedenken en op eigen houtje de oude waardes "deprecated" te verklaren, zodat documenten daarmee gemaakt nooit meer compatible zijn.
@Bolleke
Je conversievoorbeeld is niet handig. Je kunt dan dus dergelijk bestanden niet geautomatiseerd converteren. Na een geautomatiseerde conversie van een bestand met een password hash kun je in het resulterende ODF bestand wel de hash overnemen maar in ODF bestand niet meer zien welk algoritme de password hash gebruikt en met welke eigenschappen (bv salt). In OOXML kan dat bijvoorbeeld wel
Ik dacht dat ze allebei gewoon ZIP gebruikten. Los daarvan, lekker boeien, dat is natuurlijk geen reden waarom MS Office er niet mee om zou kunnen gaan - hoogstens iets dat je liever beter had gezien. Zodra ik ergens een bak met de nieuwste Office vind zal ik dat trouwens eens testen
Packaging bestaan uit meer dan alleen de zip container.
Als je in een ODF document een plaatje vervangt dan moet je het totale XML bestand doorzoeken op referenties naar dat bestand in het package om te zien of je het originele plaatje ook op een andere plaats moet aan passen. In de OOXML packages staan alle file verwijzingen in kleine seperate relationship files en hoef je alleen die te doorzoeken. Ook kun je uit de relationship files die misschien maar 1% van een OOXML file vormen in 1 keer terugvinden welke URL's daar te vinden zijn of verwijzingen naar externe documenten. Handig als je bijvoorbeeld een dergelijke externe verwijzing wilt wijzingen.
Stel bijvoorbeeld dat ik de website van het hetnet.nl in een document wil omzetten naar kpn.nl/internet. Dat staat deze link bij OOXML document alleen in de relationship files maar bij ODF kan de link overal in het package voorkomen.
en het zelfde met bijvoorbeeld koppelingen naar externe datasources (zoals ODBC koppelingen) en weet ik veel wat nog meer.
ODF ondersteunt gewoon MathML. Dus graag iets duidelijker aangeven wat je bedoelt, want op het eerste gezicht is verifieerbaar onwaar wat je zegt.
MathML intergreert niet met de ODF office XML. Je kunt tussen de math tags geen andere tags toepassen. Het is in feite embedded code.
Zo kun je bijvoorbeeld geen revisie tag opnemen in MathML delen van een document. Of review informatie toevoegen in een Math deel of bijvoorbeeld voetnoten met aanvullende uitleg. In OOXML kun je de Math elementen juist wel intergreren met met normale Office tags. Als je dus een deel van een complexe Math formule verandert dan kun je dat in OOXML exact zichtbaar maken.
Dat is ook het verschil tussen een standaard die een presentatie web formaat hergebruikt gebruikt bedoelt voor het maken van een statisch webpagina of een office formaat waarin zaken voorzien worden als revisies, versieverschillen, reviews en dergelijk.
MathML intergreert niet met de ODF office XML. Je kunt tussen de math tags geen andere tags toepassen. Het is in feite embedded code.
Dat klopt, het is namelijk MathML :)
Zo kun je bijvoorbeeld geen revisie tag opnemen in MathML delen van een document.
Zonder me erin ingelezen te hebben: is het dan niet de bedoeling dat je die om de betreffende sectie heenplakt? Kijk eens hoe OOo daarmee omgaat zou ik zeggen.
Zo kun je bijvoorbeeld geen revisie tag opnemen in MathML delen van een document.
Tja, geen idee. Er is van alles in ODF om changes te tracken (o.a. binnen spreadsheets), maar ook dit zouden we eens moeten testen. Dat het niet *binnen* een MathML stuk kan lijkt me logisch, want dat zou dan niet meer valideren. Maar volgens mij staan al die changes sowieso buiten de eigenlijke content in een aparte lijst zodat de eigenlijke data niet vervuild wordt. Dan zou een MathML wijziging ook gewoon meegenomen moeten kunnen worden. Ik zal dat straks in mijn lunchpauze eens testen.
MathML intergreert niet met de ODF office XML. Je kunt tussen de math tags geen andere tags toepassen. Het is in feite embedded code.
Maar het is wel embedded code, ook in de vorm van een open standaard, en dus zonder vendor-specifieke kennis bruikbaar.
OMML is ook een open standaard en is ook zonder vendor specifieke kennis bruikbaar.
Maar OMML functioneert ook nog eens goed volledig geintegreerd in een office document formaat en MathML eigenlijk niet.
Een voordeel van OMML is de integratie, een nadeel is de enorme overhead. Overigens kan "gewoon" MathML ook acteren als een geïntegreerd onderdeel, maar dat ziet er dan anders uit.
De overhead van Office MathML (OMML) is noodzakelijk om op de wijze zoals dit functioneert te kunnen integreren in de document-layout. Dit zeggen de voorstanders van OMML.
Het is een interessante link die je toont, ik zou er een voorstander van zijn indien ODF zou migreren naar OMML, dit is makkelijk, omdat OMML compatible is met MathML, via een XSLT conversie kan er van MathML naar OMML worden gegaan.
Ik ben er een voorstander van dat dit in de volgende ODF versie wordt geregeld. Goed punt./
Concrete voorbeelden, graag, op welke punten OOXML meer grafische ondersteuning zou bieden dan ODF. Loze kreten hebben we niks aan. Tja, je hebt kritiek dus die zul je moeten onderbouwen...
Dat zou in een reactie comment te veel werk zijn. Er zijn grote verschillen.
Ik kan je wel een leuk voorbeeld geven uit de praktijk.
Als je een grafisch SVG element in bijvoorbeeld MS Office 2007 plakt dan kan MS Office deze omzetten naar native VML of DrawingML en wordt het element een stuk native OOXML dat je ook kan bewerken. Bijvoorbeeld OpenOffice kan dat niet omdat de zogenaamde SVG compatible ondersteuning in ODF veel beperkter is. Dus OpenOffice zal SVG elementen altijd embedden vergelijkbaar met binaire picture formaten als PNG.
Dat zou in een reactie comment te veel werk zijn. Er zijn grote verschillen.
Zie mijn opmerking hiervoor over een open brieven-uitwisseling ;-)
Ik kan je wel een leuk voorbeeld geven uit de praktijk.
Als je een grafisch SVG element in bijvoorbeeld MS Office 2007 plakt dan kan MS Office deze omzetten naar native VML of DrawingML en wordt het element een stuk native OOXML dat je ook kan bewerken. Bijvoorbeeld OpenOffice kan dat niet omdat de zogenaamde SVG compatible ondersteuning in ODF veel beperkter is. Dus OpenOffice zal SVG elementen altijd embedden vergelijkbaar met binaire picture formaten als PNG.
Maar waarom zou je in je tekstverwerker een plaatje willen kunnen bewerken? Los daarvan, als OOo een SVG-editor zou hebben zou het wel kunnen - dit is dus een kritiek van jou op een implementatie, niet op een specificatie. Je haalt twee dingen door elkaar en dat maakt de discussie er niet helderder op; als ik je goed begrijp is MS Word tegenwoordig ook een tekenpakket en zou die dus ook gewoon SVG in ODF moeten kunnen tekenen.
Trouwens, juist het omzetten naar een ander formaat brengt allerlei compatibiliteitsissues met zich mee (kun je het weer exporteren naar SVG zonder dataverlies? If so, waarom gebruiken ze dan niet gewoon SVG? In hoeverre is SVG 100% compatible met DrawingML en VML? Etc.).
(Is trouwens OOo Draw daar niet voor? Ik gebruik dat eigenlijk nooit.)
Maar waarom zou je in je tekstverwerker een plaatje willen kunnen bewerken?
Bijvoorbeeld omdat het het een bepaalde pijl of een ander grafisch element in je presentatie is en je die pijl een iets andere hoek of kleur wilt geven. Ik had bijvoorbeeld laatst een presentatie met allerlei grafisch stroomdiagram elementen. Dat zag er op een beeldscherm prima uit maar geprojecteerd was het veel te flets en heb ik even in powerpoint de kleuren van die grafische elementen aangepast.
Wat ik bij jou opmerking telkens tegenkom is dat jij zaken niet zo zou gebruiken of zo zou inrichten. Dat is echter wel een keuzemogelijkheid die je krijgt als je formaten hebt die deze mogelijkheden ondersteunen. Dat laat echter onverlet dat jij en degenen die dat met je eens zijn gewoon ODF kunnen gebruiken en niet over dergelijk uitgebreidere maar misschin qua implementatie complexere mogelijkheden zullen beschikken. Dat is nou keuzevrijheid.
Ik denk echter wel dat de bovenstaande discussie duuidelijk maakt dat er veel verschillen zijn die niet zo maar even opgelost kunnen worden maar ook duidelijk een andere visie vertegenwoordigen qua inrichting van een Office document.
En dat is prima. Maar dan vind ik dat het juist ook heel logisch is dat er meerdere formaten gebruikt worden en dat niet de ene visie over office documenten moet worden opgedrongen aan alle implementaties door een formaat voor te schrijven wat die andere visie niet ondersteunt. Daarom ben ik dus ook voor de standaardisatie van beide formaten.
Natuurlijk is er bij OOXML is ruimte voor verbetering en bij ODF ook, maar het is niet zo maar even evident dat ODF geschikt is voor alle zaken waar OOXML geschikt is en omgekeerd waarschijnlijk ook.
Dat zag er op een beeldscherm prima uit maar geprojecteerd was het veel te flets en heb ik even in powerpoint de kleuren van die grafische elementen aangepast.
a) Powerpoint != Word. (Dat zal in OOo Impress ook vast kunnen, maar ik gebruik die ellende nooit want ik heb een hekel aan dat soort presentaties dus dat weet ik domweg niet zeker.)
b) Dit gaat dus wederom *NIET* over het formaat ODF maar over een applicatie. Als MS Office dat kan en OOo kan het niet en jij vindt het handig: prima, maar dat heeft dus werkelijk *niks* met het documentformaat te maken.
Jij pakt nu een bepaalde functie uit MS Office die OOo (kennelijk?) niet heeft om aan te tonen dat OOXML beter is dan ODF, terwijl het *formaat* ODF die functionaliteit op werkelijk geen enkele wijze onmogelijk maakt. Dat vind ik een hele rare en tendentieuze redenering die je positie niet versterkt.
Wat ik bij jou opmerking telkens tegenkom is dat jij zaken niet zo zou gebruiken of zo zou inrichten. Dat is echter wel een keuzemogelijkheid die je krijgt als je formaten hebt die deze mogelijkheden ondersteunen.
Nogmaals, er is niks aan het formaat dat zegt "dit kan niet". Dat zou ook raar zijn, HTML schrijft ook niet voor dat je het moet editen met vi of emacs of juist FrontPage, en of een editor wel of niet een "kopieer dit menu naar alle pagina's"-functie moet ondersteunen.
Verder zijn we het fundamenteel oneens over de vraag of optimalisatie in een document thuishoort of in een applicatie. Tja, dat kan, maar de calcChain is bijv. volgens mij niet optioneel (but correct me if I'm wrong). Dat is dus geen keuze maar een (in mijn ogen rare) verplichting, terwijl ODF juist deze keuze aan de applicatiebouwer laat.
Daarnaast negeer jij mijn stelling dat het heen en weer converteren tussen allerlei formaten mogelijk niet bevorderlijk is voor de kwaliteit van data (import SVG in Office > DrawingML > aanpassen > export naar SVG). Als DrawingML 100% compatibel is met SVG is er dus geen enkele reden voor MS geweest om daar weer iets nieuws voor te bedenken (behalve de bekende redenen).
Mijn simpele vraag aan jou is dus: wat kan DrawingML dan dat SVG niet kan en kennelijk zo volstrekt onmisbaar is voor OOXML dat er een compleet nieuw iets voor moest worden bedacht?
Jij vroeg expliciet naar een voorbeeld waarom je een plaatje zou willen bewerken in een office programma:
Maar waarom zou je in je tekstverwerker een plaatje willen kunnen bewerken?
Geef ik een voorbeeld waarom je een plaatje zou willen bewerken in powerpoint (heel vergelijkbaar omdat het ook OOXML files bewerkt) en dan ga je zeuren dat ik het over applicatie spcifiek iets heb. Ik heb gewoon je vraag beantwoord met een heel valide voorbeeld.
Je moet wel consequent blijven.
Zowel OOXML als ODF hebben grafische elementen die je dus ook zal kunnen bewerken in een office suite. OOXML kan daarbij gewoon meer dan ODF met name omdat Office meer mogelijkheden biedt dan OpenOffice.
De draw functionaliteit in ODF is namelijk vrijwel 1 op 1 de functionaliteit uit het oude OpenOffice formaat en dat is gewoon veel beperkter dan de functionaliteit in bijvoorbeeld MS Office en is bovendien niet gelijk aan de functionaliteit uit SVG.
Goed, ik ben nu wel even klaar met deze discussie omdat we in cirkeltjes om elkaar heen aan het draaien zijn:
Jij vroeg expliciet naar een voorbeeld waarom je een plaatje zou willen bewerken in een office programma:
Maar waarom zou je in je tekstverwerker een plaatje willen kunnen bewerken?
Merk op dat ik zeg *tekstverwerker*, niet *presentatieopmaakpakket*. Je verdraait mijn vraag dus en beantwoordt hem niet. Dat er een vectortekenpakket bijzit lijkt me logisch (OOo Draw bijv.), dus dat hoef ik je ook niet te vragen.
Geef ik een voorbeeld waarom je een plaatje zou willen bewerken in powerpoint (heel vergelijkbaar omdat het ook OOXML files bewerkt)
Nee, want in een presentatieopmaakpakket verwacht ik het wel, in een tekstverwerker niet. Dan ga ik me dus ofvragen of het soms in OOo Impress wel kan, maar ik gebruik dat dus nooit.
en dan ga je zeuren dat ik het over applicatie spcifiek iets heb
Dat stond er los van...
OOXML kan daarbij gewoon meer dan ODF met name omdat Office meer mogelijkheden biedt dan OpenOffice.
Dat is dus gewoon kul. Het feit dat je een getekend pijltje in OOo Writer niet kunt aanpassen en in MS Word (misschien) wel heeft niks te maken met het formaat. Je kunt dat ook vanuit Word namelijk opslaan als 1 van 6 miljard ondersteunde formaten, waaronder met behulp van de Sun-plugin ODF.
De draw functionaliteit in ODF is namelijk vrijwel 1 op 1 de functionaliteit uit het oude OpenOffice formaat en dat is gewoon veel beperkter dan de functionaliteit in bijvoorbeeld MS Office en is bovendien niet gelijk aan de functionaliteit uit SVG.
Tja, jij zegt het, ik kan dat niet weerleggen zonder specifieke voorbeelden. Maar goed, ik neem aan dat de tekenfunctionaliteit in OOXML dan ook 1 op 1 de functionaliteit uit MS Office nabootst?
Ik weet niet of dat beperkter is, ik teken nooit in mijn tekstverwerker. Ik weet het gewoon niet en kan het zonder voorbeelden ook niet beoordelen.
Als DrawingML 100% compatibel is met SVG is er dus geen enkele reden voor MS geweest om daar weer iets nieuws voor te bedenken (behalve de bekende redenen).
Mijn simpele vraag aan jou is dus: wat kan DrawingML dan dat SVG niet kan en kennelijk zo volstrekt onmisbaar is voor OOXML dat er een compleet nieuw iets voor moest worden bedacht?
DrawingML is bijvoorbeeld uitgebreider dan SVG en bevat naar vestro graphics features die niet slecht betrekking hebben op een individueel grafisch element maar die ope meerdere plaatsen kunen worden toegepast.
Bijvoorbeeld
* SVG is bijvoorbeeld een 2D formaat en DrawingML heeft 3D effecten.
* DrawingML biedt de mogelijkheid van aparte thema files.
Is trouwens OOo Draw daar niet voor?
Je kunt dat nu gerust ODF draw noemen omdat OASIS de OpenOffice draw elementen vrijwel ongewijzigd in ODF heeft opgenomen (waar natuurlijk DrawingML eigenlijk een representatie is van de MS Office drawing mogelijkheden).
De OpenOffice draw elementen zijn echter gewoon wat beperkter qua grafische functionaliteit en wat ruimer qua embedding functionaliteit dan de OOXML elementen.
Je kunt dat nu gerust ODF draw noemen
NEE, want ik had het over de APPLICATIE, niet het FORMAAT. Wil je die 2 alsjeblieft uit elkaar houden?
Daarnaast gaat ODF Draw alleen over de opname van grafische elementen en de opbouw van grafische documenten, niet over de taal waarin de elementen an sich zijn beschreven (dat is namelijk gewoon SVG, met een lichte extensie).
Daarnaast gaat ODF Draw alleen over de opname van grafische elementen en de opbouw van grafische documenten, niet over de taal waarin de elementen an sich zijn beschreven (dat is namelijk gewoon SVG, met een lichte extensie).
Dat idee krijg je wel als je misschien een beschrijving leest van ODF maar als ik dit lees
januari 21. 2008 02:59
In the ODF schema, there are 9 elements in the SVG-compatible
namespace. They are as follows:
svg:desc,
svg:font-face-src,
svg:font-face-uri,
svg:font-face-format,
svg:font-face-name,
svg:definition-src,
svg:linearGradient,
svg:radialGradient, and
svg:stop.
Where are the basic primitives of SVG such as rect, circle, ellipse, line, polyline, and polygon? They do not exist in
the SVG-compatible namespace. Something similar to them
appear in the draw namespace, which is specific to ODF.
Anon
Bron
Dat lijk me volstrekt in tegenspraak met wat jij hier beweert.
Let ook op dat ODF in tegenstelling tot bij mathML niet de w3c namespace hanteert maar 3 eigen openoffice namespaces voor draw elementen (svg-comatible, draw en draw3D)
Er zijn nog zat redenen waarom ODF niet geschikt is voor Microsofts gebruik in met name MS Office. Een paar voorbeeldjes
De engiste reden dat ODF niet geschikt is voor Microsoft om in Office te gebruiken is dat Microsoft ODF niet zo eenvoudig kan manipuleren om haar monopolie te beschermen. De rest is marketing.
* ODF bevat geen performance optimalisaties voor bijvoorbeeld spreadsheets
Die performance optimalisaties moeten ook niet in het bestand plaatsvinden maar in de applicatie. Het bestand zelf moet volledig schoon zijn van applicatie specifieke troep, zo klein mogelijk zijn en geen overbodige informatie bevatten.
Performance optimalisties zijn zowel applicatie specifiek, dragen bij aan een grotere lengte van het bestand en zijn overbodig om eenduidig weer te geven wat er in een bestand staat.
Het opnemen van performance optimalisaties is dus een fundamentele ontwerpfout in OOXML.
* ODF biedt geen backwards compatibliteit met bestaande documenten (zoals bijvoorbeeld te zien bovenstaand password hashing voorbeeldje)
Backwards compatibiliteit is ook weer typisch iets dat je moet oplossen in de applicatie en niet in het bestandsformaat. Als je dit anders aanpakt maakt je simpelweg een enorme ontwerpfout.
* ODF heeft veel beperktere grafische feature ondersteuning
ODF gebruikt SVG, en SVG is volledig. Dus hier kan ik me erg weinig bij voorstellen.
* ODF heeft geen met de office functionaliteit intergreerbare Math ondersteuning zoals OOXML
ODF gebruikt MathML. Nu laat MathML nog wel het een en ander te wensen over maar je kan dit onmogelijk inferieur aan het systeem van MS-Office noemen. Als MathML niet integreerbaar is in met de Office functionaliteit is hier duidelijk een probleem met Office en niet met MathML.
Voor mensen die geen ervaring hebben met het invoeren van wiskundige vergelijkingen is het overigens waarschijnlijk niet te bevattten hoe lachwekkend het wel niet is om begrippen als 'office functionaliteit' en 'Math ondersteuning' in een zin te combineren.
* ODF is afhankelijk gemaakt van een aantal w3c webstandaarden.
Het hergebruik van standaarden is juist een goede zaak. We raken hier een fundamenteel punt, dit heeft met name ook betrekking op MathML en SVG. Zoals Bolleke al aangeeft verkort het hergebruik van standaarden de learning-curve en verhoogt dit de interoperabiliteit.
Daarnaast verhoogt het natuurlijk de efficientie. Aanpassingen hoeven slechts op 1 plek gedaan te worden in plaats van op honderden plekken. Het wiel hoeft maar 1 keer uitgevonden (in het geval van Microsoft aangekocht) te worden in plaats van steeds opnieuw.
Belangrijkste voordeel is echter dat het hergebruik van standaarden voldoet aan het paradigma van modulair ontwerp. Dit is zo'n verschrikkelijk belangrijk punt.
ODF gebruikt SVG, en SVG is volledig. Dus hier kan ik me erg weinig bij voorstellen
Daar ben je dan in de propaganda van ODF aan het vallen.
http://www.idippedut.dk/post/2008/01/Embrace-and-extend---SVG-revisited.aspx
De zogenaamde SVG ondersteuning van ODF is beperkt en slechts gedeeltelijk SVG compatible.
Die performance optimalisaties moeten ook niet in het bestand plaatsvinden maar in de applicatie. Het bestand zelf moet volledig schoon zijn van applicatie specifieke troep, zo klein mogelijk zijn en geen overbodige informatie bevatten.
De performance optimalisaties in OOXML zijn juist volledig applicatie onafhankelijk en alleen overbodige informatie als je performance relatief niet belangrijk vind.
ODF gebruikt MathML. Nu laat MathML nog wel het een en ander te wensen over maar je kan dit onmogelijk inferieur aan het systeem van MS-Office noemen. Als MathML niet integreerbaar is in met de Office functionaliteit is hier duidelijk een probleem met Office en niet met MathML.
Ik zei toch duidelijk dat MathML juist ook niet integreerbaar is met ODF en alleen embedded kan worden gebruikt.
Verder kun je MathML heel goed inferieur noemen aan OMML. er zijn hele structurele problemen met MathML in bijvoorbeeld interoperabiliteit qua implementaties.
In fact today, MathML 2 is able to encode less script structures than ISO-12083 like mathematical markup when ISO-12083 used _less_ elements than MathML.
In fact, due to unusual complexity of markup for scripts, one finds MathML tools (e.g. IteX, ASCIIMathML...) encoding scripts via hints and tricks. For example, the tensors of general relativity are being encoded as tricky combinations of msub and mrow elements instead using the correct mmultiscripts tag.
I says this because standarization is being claimed to be a advantage of ODF over Microsoft 'own' format, but anyone who worked in mathematical markup with a bit of detail knows that advantages of being a standard claimed for MathML are lost thanks to the 'infinite' variability in the codes generated by MathML tools.
Take the 15 diferent examples i elements i introduced in
[http://lists.w3.org/Archives/Public/www-math/2006Jul/0120.html]
we simply do not know how will be encoded by different MathML tools.
I will download the ECMA draft and provide feedback when find some time. I also wait to provide some 'stylesheets' to|from CanonML format is under active research.
About original goals of MathML, well... One of ironies of the "math for the web" (MathML) is in its unfriendly web design doing implementation in browsers difficult and/or impossible (parsing, CSS, DOM queries...). That is one reasons that after many years only Mozilla (and W3C Amaya) obtained native support (for part) of MathML.
In fact, one of the plans of the MathML 3 WG is the study of further changes to current spec for favouring the implementation in future browsers.
About how MathML 'works' in computation, well it is time to remember some clarifications from Neil Soiffer (one of MathML authors and recognized expertise in computer algebra systems):
<blockquote>
Content MathML is <em>not</em> really designed for computation.
MathML purposely does not contain an "evaluate" token.
What a MathML application should do when it receives the following is not defined
<apply> <sin/>
<apply><divide/>
<cn type="constant"> &pi; </cn>
<cn>4</cn>
</apply>
</apply>
</blockquote>
The emphasis is in the original.
Juan R.
Center for CANONICAL |SCIENCE)
Dus het niet compatiblele hergebruik van SVG en het hergebruik van de bepaald niet ideale MathML w3c standaard maken ODF zeker niet beter dan OOXML.
Daar ben je dan in de propaganda van ODF aan het vallen.
Dat is (a) geen argument en (b) incorrect.
De zogenaamde SVG ondersteuning van ODF is beperkt en slechts gedeeltelijk SVG compatible.
Dat is een discussie op zichzelf. In feite zou je er goed aan doen niet klakkeloos alles over te nemen wat je op blogs leest.
Wat ik zei is dat SVG compleet is.
ODF hergebruikt open standaarden, oa dus SVG. Ontwerptechnisch is dat de juiste keuze.
De performance optimalisaties in OOXML zijn juist volledig applicatie onafhankelijk en alleen overbodige informatie als je performance relatief niet belangrijk vind.
Waar haal je vandaan dat ik performance niet belangrijk vind? Ik herhaal wat ik zei: die performance optimalisaties moeten ook niet in het bestand plaatsvinden maar in de applicatie.
Performance optimalisaties kunnen aanwezig zijn in het interne documentsmodel, desnoods in een tijdelijk bestandje. Maar niet in het betandsformaat zelf. Als je dat soort zaken in het bestandsformaat kwijt moet is dat een ontwerpfout.
Ik zei toch duidelijk dat MathML juist ook niet integreerbaar is met ODF en alleen embedded kan worden gebruikt.
Er is een verschil tussen 'integreerbaar' en 'integraal onderdeel van'. Verschillende module's kun je met elkaar integreren, dat is een voorbeeld van degelijk ontwerp. Een integrale monolitische 'blob' is een voorbeeld van zeer slecht ontwerp.
Verder kun je MathML heel goed inferieur noemen aan OMML. er zijn hele structurele problemen met MathML in bijvoorbeeld interoperabiliteit qua implementaties.
MathMl behoeft helaas nog vele verbeteringen. Voordeel van het modulaire ontwerp van ODF is dat een verbetering in MathML een verbetering in ODF is.
Het zou een mooie stap zijn als men tot de ontwikkeling van een echt goede beschrijvingstaal van mathematische expressies zou overgaan (AMS-LaTeX met XML syntax bijvoorbeeld) en deze dan inplugbaar in ODF zou maken, maar op dit moment is MathML de beste keuze.
In fact today, MathML 2 is able to encode less script structures than ISO-12083 like mathematical markup when ISO-12083 used _less_ elements than MathML.
...
Juan R.
Center for CANONICAL |SCIENCE)
Het is weer het oude liedje. Je vlucht in een detail om de conclusie op de hoofdpunten te ontlopen. Moet ik de eindeloze discussie in herinnering brengen over het feit of glyph nou wel of niet een normaal Engels woord is? Of de discussie of een 'call for participation' nou wel of niet hetzelfde is als een uitnodiging? Je gebruikt dit soort dwaalsporen om niet in te hoeven gaan op de hoofdpunten van een discussie.
Ook het MathML stukje dat je gecopy/pasted hebt van de blog van Brian Jones moeten we in dit licht zien. Laat mij een korte hint geven. MathML heeft, zeker binnen ODF, als doel weer te geven hoe een mathematische expressie er uit ziet en niet wat de mathematische inhoud ervan is. Die twee zaken zijn in feite ook exclusief.
MathML heeft, zeker binnen ODF, als doel weer te geven hoe een mathematische expressie er uit ziet
Binnen OOXML is het echter ook nog gewenst dat de Math gemuteerd, ,opgemaakt, gereviewed, versie vergeleken kan worden zoals ook met andere tekstuele onderdelen van een office document mogelijk is en daar is MathML helemaal niet geschikt voor. De MathML in ODF is namelijk origineel bedoeld voor statische presentatie op bijvoorbeeld een webpagina en niet voor een editable documentstandaard.
Ik heb over de tegenstelling tussen hoe een mathematische expressie er uit ziet aan de ene kant en wat de mathematische inhoud ervan is aan de andere kant. Heb je dat nu werkelijk niet begrepen?
Ik denk dat jij gewoon niet begrijpen wil dat MathML (de door ODF gebruikte presentations set) niet bedoeld is voor een Office document omdat je er geen office functionaliteit op kunt toepassen.
Misschine moet je even een gezond artikel lezen over hoe dat in een office document uitpakt:
idippedut.dk/po...L-and-OMML.aspx
Bovenstaan artikel geeft duidelijk aan hoe OMML in een office document duidelijk superieur is aan MathML dat misschien wel heel geschikt is voor statische webpagina's maar in een office document geen toegevoegd waarde creert die juist OMML wel creert.
Ik heb een aantal comments gegeven in dit item. Keer op keer negeer je de hoofdlijn. Je quote dan 1 zinnetje en brengt daar een onzin argument (meestal een link naar een ms-blog) tegenin. Zoals een aantal mensen met meer geduld dan ik al regelmatig hebben aangetoond begrijp je zelf niet eens waar deze blogs overgaan.
Vergelijk nou zelf eens mijn posts met de reacties die je daar op geeft. Hebben die nou werkelijk met elkaar te maken?
Wat ik aangeef is dat er een verschil is tussen de _typografische representatie_ van een mathematische expressie en wat de _betekenis_ is van een mathematische expressie. Vervolgens ga je doodleuk verder alsof ik het heb over het verschil tussen een typografische representatie in een webpagina en in een Office document. En op dat punt komt je dan zelfs nog met niet kloppende argumenten.
Als je doel met dit alles is een normale discussie onmogelijk te maken door deze volledig te overspoelen met ongerelateerde onzin dan slaag je meestelijk in je opzet. Mocht het je doelstelling zijn om door met middel van het copy/pasten van zoveel mogelijk onzin uit verzamelde blogs posting mensen ervan te overtuigen dat je daadwerkelijk verstand van zaken hebt dan zou ik je adviseren op een andere taktiek over te stappen.
Volgens mij was mijn punt al van de eerste reactie waarin ik Math noem dat MathML niet goed intereert met een Office formaat en alleen als embedded code blokken kan worden gebruikt. Dat is waarom het niet
Jij probeert het verhaal daarvan weg te leiden met een verhaal over mathematische expressie en inhoud. Dat is niet zo relevant. Het is bekend dat MathML op mathematisch inhoud op bepalde delen volstrekt niet niet voldoet en nodig moet worden vervangen door een nieuwe versie. Ofwel, mathml is een ver van goede standaard en hoog nodig aan verbetering toe.
Maar de essentie van waarom het geen goede standaard is juist voor een Office document blijft hetzelfde en kan ik niet beter onder woorden brengen dan dit lid van het Deense standaardscommitee:
idippedut.dk/po...L-and-OMML.aspx
[quote]Jij probeert het verhaal daarvan weg te leiden met een verhaal over mathematische expressie en inhoud. Dat is niet zo relevant.[\quote]
Dat is relevant omdat het precies die denkfout is die men maakt in de door jou gecopy/paste reactie op de Brian Jones blog.
Met deze blogposting sla jij dus een ander spoor in. Ik ga daarop in. En nu beschuldig je mij ervan dat ik het over zaken heb die niet relevant zijn. Dat is typisch.
[quote]Het is bekend dat MathML op mathematisch inhoud op bepalde delen volstrekt niet niet voldoet[\quote]
Dat is misschien wel bekend, maar niet bij jou. De mathematische inhoud is niet relevant voor een tekstverwerker. Dat is ook de denkfout die je maakt door die blogposting te copy/pasten. Men heeft daar kritiek op de opslag van mathematische inhoud middels MathML, maar dat is helemaal niet relevant voor de typografische representatie.
Ik ga ook niet beweren dat OOXML een slechte standaard is omdat het MS-Office niet helpt begrijpen wat de inhoud is van een bepaald stuk tekst, dat soort argumenten snijden geen hout. Als ik een boek schrijf moet mijn tekstverwerker dat goed opslaan. Slechts weinigen zullen van een tekstverwerker verwachten dat deze begrijpt waar het boek over gaat. In ieder geval zou dat technisch ook niet mogelijk zijn.
[quote]en nodig moet worden vervangen door een nieuwe versie.[\quote]
<cynisch>Dus zolang MathML de functionaliteit van bijvoorbeeld Mathematica niet ondersteund is het niet geschikt om gebruik van te maken in een tekstverwerken?</cynisch>
Zo beter :)
Jij probeert het verhaal daarvan weg te leiden met een verhaal over mathematische expressie en inhoud. Dat is niet zo relevant.
Dat is relevant omdat het precies die denkfout is die men maakt in de door jou gecopy/paste reactie op de Brian Jones blog.
Met deze blogposting sla jij dus een ander spoor in. Ik ga daarop in. En nu beschuldig je mij ervan dat ik het over zaken heb die niet relevant zijn. Dat is typisch.
Het is bekend dat MathML op mathematisch inhoud op bepalde delen volstrekt niet niet voldoet
Dat is misschien wel bekend, maar niet bij jou. De mathematische inhoud is niet relevant voor een tekstverwerker. Dat is ook de denkfout die je maakt door die blogposting te copy/pasten. Men heeft daar kritiek op de opslag van mathematische inhoud middels MathML, maar dat is helemaal niet relevant voor de typografische representatie.
Ik ga ook niet beweren dat OOXML een slechte standaard is omdat het MS-Office niet helpt begrijpen wat de inhoud is van een bepaald stuk tekst, dat soort argumenten snijden geen hout. Als ik een boek schrijf moet mijn tekstverwerker dat goed opslaan. Slechts weinigen zullen van een tekstverwerker verwachten dat deze begrijpt waar het boek over gaat. In ieder geval zou dat technisch ook niet mogelijk zijn.
en nodig moet worden vervangen door een nieuwe versie.
<cynisch>Dus zolang MathML de functionaliteit van bijvoorbeeld Mathematica niet ondersteund is het niet geschikt om gebruik van te maken in een tekstverwerken?</cynisch>
Nee dat was niet relavant voor het gebruik in een office suite maar was slecht om aan te geven dat MathML niet superieur is qua standaard. Ook het presentatie deel heeft allerlei issues omdat van bepaalde zaken niet duidelijk is hoe ze eenduidig in MathML gerepresenteerd moeten worden. Daardoor is de MathML gegenereerd door gui math edit tools vaak niet goed interoperabel.
Dat is echter minder relavant voor een office suite (hoewel misschien wel relevant voor ODF's interoperabiliteit).
Veel meer relevant voor deze discussie over ODF/OOXML blijft echter dat MathML gewoon veel minder geschikt is voor een editable office document formaat vergeleken met OMML en de links naar de blog post die ik heb toegevoegd laten dat heel goed zien met voorbeelden.
Dat is het issue waar ik telkens op hamer maar waar jij verder niet op inga.
[quote]Nee dat was niet relavant voor het gebruik in een office suite maar was slecht om aan te geven dat MathML niet superieur is qua standaard.[/quote]
[quote]
Niet superieur als standaard aan wat?
Omdat het geen goede standaard is om de mathematische inhoud van een expressie weer te geven is het geen superieure typografische standaard? Heb je enig idee hoe onlogisch die redenering is?
[quote]Ook het presentatie deel[/qoute]
Ook?
Er is geen ook, het gaat alleen om de presentatie van expressies.
heeft allerlei issues omdat van bepaalde zaken niet duidelijk is hoe ze eenduidig in MathML gerepresenteerd moeten worden. Daardoor is de MathML gegenereerd door gui math edit tools vaak niet goed interoperabel.
Dat is echter minder relavant voor een office suite (hoewel misschien wel relevant voor ODF's interoperabiliteit).
Veel meer relevant voor deze discussie over ODF/OOXML blijft echter dat MathML gewoon veel minder geschikt is voor een editable office document formaat vergeleken met OMML en de links naar de blog post die ik heb toegevoegd laten dat heel goed zien met voorbeelden.[/quote]
Uit blog post nummer 1: MathML purposely does not contain an "evaluate" token.
Deze posting gaat niet om de typografische aspecten. Ze praten over iets wat niet relevant is. Tevens trekken ze dezelfde conclusie als ik, MathML is geen opslag formaat voor mathematische inhoud.
Uit blog post nummer 2: Most of the things I have shown above are imo due to errors in the implementation of OpenOffice.org where MathML is clearly not implemented correctly.
Dit gaat duidelijk niet over een tekortkoming van MathML, maar over een implementatie fout in OpenOffice. Dit zal men dus moeten repareren in OpenOffice en heeft helemaal niets te maken met MathML en/of als standaard.
Kortom die blogposts ondersteuenen totaal niet jouw opvattingen. Het enigste wat zij ondersteunen is jouw wanbegrip van de hele materie.
Die edit functie zou toch wel handig zijn.
Nee dat was niet relavant voor het gebruik in een office suite maar was slecht om aan te geven dat MathML niet superieur is qua standaard.
Niet superieur als standaard aan wat?
Omdat het geen goede standaard is om de mathematische inhoud van een expressie weer te geven is het geen superieure typografische standaard? Heb je enig idee hoe onlogisch die redenering is?
Ook het presentatie deel
Ook?
Er is geen ook, het gaat alleen om de presentatie van expressies.
heeft allerlei issues omdat van bepaalde zaken niet duidelijk is hoe ze eenduidig in MathML gerepresenteerd moeten worden. Daardoor is de MathML gegenereerd door gui math edit tools vaak niet goed interoperabel.
Dat is echter minder relavant voor een office suite (hoewel misschien wel relevant voor ODF's interoperabiliteit).
Veel meer relevant voor deze discussie over ODF/OOXML blijft echter dat MathML gewoon veel minder geschikt is voor een editable office document formaat vergeleken met OMML en de links naar de blog post die ik heb toegevoegd laten dat heel goed zien met voorbeelden.
Uit blog post nummer 1: MathML purposely does not contain an "evaluate" token.
Deze posting gaat niet om de typografische aspecten. Ze praten over iets wat niet relevant is. Tevens trekken ze dezelfde conclusie als ik, MathML is geen opslag formaat voor mathematische inhoud.
Uit blog post nummer 2: Most of the things I have shown above are imo due to errors in the implementation of OpenOffice.org where MathML is clearly not implemented correctly.
Dit gaat niet over een tekortkoming van MathML, maar over een implementatie fout in OpenOffice. Dit zal men dus moeten repareren in OpenOffice en heeft helemaal niets te maken met MathML en/of als standaard.
Kortom die blogposts ondersteuenen totaal niet jouw opvattingen. Het enigste wat zij ondersteunen is jouw wanbegrip van de hele materie.
Ik denk dat je door de namen in de war raakt:
Waarom OOML in OOXML zo geschikt is voor Office toepassingen vergeleken met MathML:
idippedut.dk/po...L-and-OMML.aspx
Waarom de hergebruikte MathML standaard in ODF na jaren mede door de beknopte beschrijving en gebrekkige XML schema controle nog niet heeft geleid tot een interoperabele implementatie in ODF implementaties zoals OpenOffice.
idippedut.dk/po...and-MathML.aspx
Een math element in ODF mag namelijk alles bevatten omdat ze het MathML schema niet wilden includen (minder pagina's is toch beter ?!). Uit de ODF spec:
<!-- To avoid inclusion of the complete MathML schema, anything -->
<!-- is allowed within a math:math top-level element -->
Jongens jongens toch, dit bedoel ik nu, eindeloos gezever over waarom wat gebruiken. Het afdrukje wat je maakt gaat het toch uiteindelijk om?
Als je deze discussie leest krijg ik een database van jullie met een excel sheet en.. en.. om de uiteindelijke resultaten te kunnen zien?
Ik heb het al eens eerder aangehaald, hoe je intern je gegevens verwerkt om tot een resultaat te komen is niet belangrijk in een discussie ODF OOXML.
Dat wat je presenteert, afdrukt, verstuurt wel. Je wilt je publiek cq klant een resultaat aanreiken en niet een complexe berekening. Deze zal dit moeten kunnen lezen, bij grote voorkeur met de door hem gekozen methode en niet met het door jouw opgelegde formaat.
In de DTP wereld, foto industrie, digitale studio's enzovoort worden vaker met voor anderen vreemde formaten gewerkt. Het resultaat kunnen we allemaal begrijpelijk lezen, zien en horen.
Dáár is de discussie, Adobe Photoshop maakt PSD's, op Internet zie ik ze als gif, jpg of zo. Orchestrator maak orc files, het resultaat beluister ik als midi of wav of mp3, Autocad, Acrobat, Cubase, In design, allemaal eigen formaten, het resultaat is het uitvoerbare bestand.
In deze discussie willen we kiezen uit een formaat dat voor iedereen overal te lezen valt.
Of je het gemaakt hebt met MS OOO WP maakt niet uit, op dit moment is de enigste en mijn voorkeur hebbende ODF formaat daarvoor gekozen.
Het hergebruik van standaarden is juist een goede zaak. We raken hier een fundamenteel punt, dit heeft met name ook betrekking op MathML en SVG. Zoals Bolleke al aangeeft verkort het hergebruik van standaarden de learning-curve en verhoogt dit de interoperabiliteit.
Juist, ja, het hergebruik van MathML vergroot de interoperabiliteit.
Laten we eens een willekeurige ODF applicaite nemen (zeg OpenOffice) en kijken hoe interoperabel die MathML eigenlijk is als de die bijvoorbeeld vanuit een echte MathML applicatie naar ODF gebruikt
Do your math - ODF and MathML
Uit de conclusie:
Luckily the ODF-spec only talks about how MathML is used in a single place - section 12.5 Mathematical Content. It says that "Mathematical content is represented by MathML 2.0 (see [MathML])". The RelaxNG-snippet provided also tells us that you can put everything into a "math area", <relax ng snippet removed>
So basically, all bets are off. I can only begin to wonder how other implementations of ODF use MathML.
Zelfs de OMML math vanuit Office open XML is via XSLT conversie nog meer interoperable met MathML dan de meest complete ODF implementatie.
Goeiedag zeg, Ik maak een geintje, en Albert ziet zijn kans schoon voor zijn marketingpraatje. Ik heb overigens geleerd dat het afkraken van een concurrerend product zich tegen je keert.
Ik laat de technische weerlegging van jouw argumenten graag aan Bolleke en Toiletpapier over, die kunnen dat veel en veel beter als ik. (ik ben geen developer)
Een ding blijft mij uit de hierna volgende discussie wel bij:
ODF heeft niet...
ODF heeft niet...
ODF heeft niet...
Waarom niet wordt prima uit de doeken gedaan.
Ik weet nu helder waarom OOXML het allemaal wel heeft.
OOXML is volledig bedoeld en toegesneden op MS-Office. Aansluiting op andere paketten is volledig oninteressant. Microsoft en MS-Office, daar gaat het om.
Hoezo open standaard...
Spreadsheetformula's
Dit is een complex onderwerp, er zijn meerdere manieren om te werken
Zoals Microsoft het heeft gedaan, Verschillende ISO standaarden genegeerd, excel-datum-bugs in de standaard opgenomen, zodat alle applicaties die met OOXML gaan werken een Excel datum bug moeten implementeren. Haastklus. Dat had zijn redenen. Er is haast omdat de markt anders voor ODF gaat kiezen. Microsoft is te laat begonnen, en kan alleen door haast proberen op tijd te zijn voor de besluitvormingen wereldwijd voor een standaard.
Niet alleen de standaard-definitie is een haastklus, ook de certificatie moet met grote haast gebeuren. Hopelijk komt er een nieuwe formula-standaard waarin de fouten in de huidige worden rechtgezet. Dit is ook ge-eist door verschillende P-members. Ik ben benieuwd of ECMA aan deze eis gehoor zal geven. Dat Ecma weinig tijd had om dit te doen is aan haarzelf te werken, het is immers Ecma (lees Microsoft) dat hemel en aarde bewogen heeft om in Fast-track te worden beoordeeld, hoewel door veel mensen dit als onverstandig werd ervaren. Het gaat immers om inmiddels 8700 pagina's. We zullen het binnekort vernemen.
Het is ook mogelijk om vooraf definiëren aan welke kwaliteits-eisen een standaard moet voldoen, en dan achteraf controleren of het afgeleverd werk aan deze eisen voldoet. Dit voorkomt gerommel zoals in OOXML heeft plaatsgevonden. Dit is het pad dat gevolgd wordt in ODF, en een dergelijk pad kost meer tijd. Dat is inderdaad een nadeel. Maar goed, wat is een jaar meer of minder om een standaard die over 50 jaar nog interpreteerbaar moet zijn.
De vooraf gestelde zorgvuldigheidseisen, en de achteraf beoordeelde standaard voorstellen zijn allemaal na te lezen, de drafts worden gepubliceerd (elke 2 a 3 maanden een nieuwe, soms enkelen per maand), en kunnen door iedereen op heldere criteria worden beoordeeld. De laatste draft is van 28 december. Op dit moment zijn er 300 functies gedefinieerd, ook betreffend inline arrays en complexe getallen. De opvatting is dat er in het totaal 400 functies gedefinieerd zullen worden. Tussen juni 2007 en december 2007 zijn er 200 gedefinieerd. Er wordt op volle stoom gewerkt.
De kritiek dat het nog niet gereed is is simpelweg terecht, want het is nog niet gereed.
Mijn persoonlijke mening is: beter zorgvuldig en langzaam dan een haastklus met legacy-bugs uit 1995 geïncorporeerd. Bugs moet je in een applicatie oplossen, niet in een standaard incorporeren.
Maar nogmaals, dit is mijn mening. Ik heb uitgelegd waarom en ben verder niet geïnteresseerd in een flame-war op niveau waar Pamela en Brian Jones zich begeven.
Laten we hopen dat OOXML de gevraagde verbeteringen heeft doorgevoerd, en op eerlijke wijze een goede ISO-standaard zal worden. Laten we hopen dat de formula-standaard snel gereed zal zijn, en misschien kunnen beide standaarden versmelten, en kan het goede van beiden leiden tot een betere office-documenten-standaard. Want uiteindelijk gaat het niet om IBM of Microsoft maar gaat het om ons.
Hier trouwens nog even de opinie van Patrick Durusau,lid van de OASIS TC voor Opendocument en voormalig project editor van de ISO standaardisatie voor ODF en voorzitter vna het amerikaase INCITS standaardscommitee, over de openheid van Office Open XML.
www.durusau.net...PosterChild.pdf
I understand that SC 34 will be taking on the maintenance and future development of OpenXML (with the participation of Ecma). That will mean that approximately 70% of the world's population will have a say (through their respective national bodies) on how OpenXML continues to develop. I can't speak for anyone other than myself but that sounds pretty open to me.
Zelfs iemand die al ruim 5 jaren lang zeer actief lid is van de OASIS TC vind de verbetering opevallend positief:
I think you can see the pattern I am trying to develop. At every stage of becoming more open, OpenXML has changed, and, at least in my opinion, has improved.
Dus zelfs de grootste voorstanders van OpenDocument kunnen prima overweg met het door Office Open XML gevolgde standaardisatie traject en de daaruitvoortgekomen sterk verbeterde specificatie en vauit de title kun je zelfs zien dat hij dit standaardisatieproces van Office Open XML zelfs ziet als een voorbeeld (posterchild) voor anderen.
Dus zelfs de grootste voorstanders van OpenDocument kunnen prima overweg met het door Office Open XML gevolgde standaardisatie traject
Als hij zegt dat 70% van de wereld populatie een stem heeft in de ballot, dan is dat zonder meer onzinnig. Bij de P-Members zijn landen als Kazachstan, Libanon, Malta en Cyprus. Kleine of dunbevolkte landen. Daarbij zijn de national bodies niet democratisch gekozen, en is er geen nationale verkiezing over hoe de national body zal stemmen, maar soms zijn ze zelfs overvallen door nieuwe leden die op zakelijk belang, niet op democratisch mechanisme binnenkwamen.
Als Patrick Durusau dit mechanisme representatief noemt voor 70% van de wereldbevolking, vrees ik dat zijn gezonde verstand hem, wat dat betreft, in de steek heeft gelaten. En als hij dat een bewijs noemt voor de openheid voor OOXML, dan vrees ik ook dat hij zaken wat betreft dit onderwerp geheel verkeerd inschat. Het kan best zijn dat OOXML wel open is, of niet open is, maar ik hoor graag andere onderbouwing daarvoor dan deze.
Daaarnaast is niet het gebrek aan openheid de belangrijkste kritiek, maar dat zijn hele andere zaken, uitstekend weergegeven door onder ander Bolleke (ik ga dat niet allemaal herhalen).
Echter, op dit moment zijn particuliere meningen, zoals die van PAtrick Durusau (hij spreekt op persoonlijke titel) niet meer van belang. Het gaat erom of OOXML voldoende P-Members heeft overtuigd op de volgende ballot-meeting einde van de maand, zo ja, dan is het een ISO standaard, zo nee, dan is het dat niet, en zal het opnieuw moeten beginnen. er is, naar ik meen, geen herkansing meer na het einde van de maand.
Tja, toch denk ik dat de mening van een erkend epxert op het gebied van zowel XML office formaten en standaardisatie van die formaten iets meer is dan zo maar een particuliere mening.
En dan jou persoonlijke mening dan is dat hij dat verkeerd inschat is nauwelijk boeiend.
Ik denk namelijk dat als OASIS TC leden met dergelijke expertise al openlijk positief zijn over OOXML standaardisatie dat dat iets meer in de schaal legt ook bij partijen die wel in het ISO proces betrokken zijn dan een anonieme commenter op webwereld die het daar niet mee eens is.
Ik denk wel dat zijn mede TC leden van IBM behoorlijk pissig zullen zijn.
Tja, toch denk ik dat de mening van een erkend epxert op het gebied van zowel XML office formaten en standaardisatie van die formaten iets meer is dan zo maar een particuliere mening.
Ook experts op het gebied van XML office formaten en standaardisatie van die formaten kunnen onzin delibreren, dat gebeurt heel regelmatig en is nu ook het geval.
Als hij zegt dat het democratisch is dat de stem van Cyprus met 200.000 inwoners + Malta met 100.000 inwoners even zwaar weegt als China samen met India, gezamenlijk bijna de halve wereldbevolking, dan heeft die man iets verkeerd begrepen. Het lijkt mij dat dan toch, zeg 40% van de wereldbevolking zwaar ondervertegenwoordigt is. Ware het al dat de national bodies ook maar iets met democratie te maken hadden. Want dat is niet zo, nergens, voor zover ik weet is er enige democratische controle op de personele invulling van den national bodies. Maar zelfs al was dat zo, dan liggen de verhoudingen fout.
Ik kan me niet voorstellen dat iemand dit serieus neemt. Behalve jij, blijkbaar.
Ik moet hier verder niet te veel op ingaan, onzin moet je links laten liggen.
Ik snap niet waarom je nu weer IBM hierbij moet slepen, het is echt een ingesleten haat-ritueel waar ik niet veel mee op heb.
Ik bendenk me net aanvullend dat hij mogelijk ook deel uitmaakt van de amerikaanse delegatie die naar de BRM gaat.
We zullen zien, 28 februari, geloof ik? Hoe de stemmen vallen.
Er is meer dan alleen openheid dat een rol speelt, veel meer.
Om te kunnen reageren, dient u ingelogd te zijn.
Unified communications biedt vele voordelen, maar heeft ook specifieke uitdagingen en niet ieder project levert het verwachte ROI op.
Downloaden
1 jaar geleden: 26 mei 2011
2 jaar geleden: 26 mei 2010
14 jaar geleden: 26 mei 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, Jobworld, MacWorld, SHUTR fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
