René Løhde (aka Rene Loehde)

Nu kunne jeg desværre ikke optage hele foredraget, eller rettere Youtube modtager kun 100 MB og max 10 min, så det klip jeg har lagt ind i min blog på http://www.version2.dk/artikel/1353 indeholder kun en del af de guldkorn Bob Sutor kom med.

Du skulle have været med der for han var god :-)

Anyway, du er velkommen til at kommentere på de version2 blog-indlæg der indtil nu er skrevet om emnet.

Der kommer nok flere i samme retning i den kommende tid.

Jeg skal gerne skære det ud i pap for dig, hvis du ikke kan forstå hvorfor jeg siger det er en elendig specifikation.

6000 sider er omkring en halv hyldemeter.  Det svarer circa til den trykte udgave af Hipparcos stjernekataloget, eller Lademans leksikon, eller det samlede sæt af ITU standarder, i den sidste version jeg så.

Der er ingen der har en jordisk chance for at implementere en standard af den størrelse og konkurrere med Microsoft og der med er standarden per definition ikke fair.

Hvis microsoft kan koge den ned til under 1000 sider, så kan vi tale om det, men de skal ikke have fordel bare ved at skrive en uklar og oppustet tekst.

Dernæst, hvis man implementere bitmaps i XML formater, så har man helt sikkert ikke fattet ideen med XML.

Hvis nogle af bit'ne så ovenikøbet har betydninger som "formatter fodnoter som et specifikt Microsoft produkt gør det", er helt hen i vejret, ikke mindst når alle microsofts licenser forbyder enhver form for reverse-engineering.

Er det så svært at forstå ?

Poul-Henning

Alias Porthos

"Angående længden på specificationen for ECMA OOXML – jeg ved ikke hvor lang noget sådan bør være, det er jo trods alt første gang man specificere sådan et dokumentformat"

Så vidt jeg ved kom ODF først og den er kun på 600-700 sider, så rent umiddelbart er Microsoft en faktor 8-10 for stor i forhold til "state of the art".

Jeg har mange års erfaringer med standarder, jeg er f.eks en af de eneste danskere der nogensinde har kodet en OSI TP4 netværks stak.

Jeg kan personligt garantere dig for at længde og kvalitet af en standard er vigtigere end noget andet for de resulterende implementeringers kvalitet.

Groft sagt, hvis du ikke kan læse dig igennem hele dokumentet på en weekend, så er det for stort, for så kan du ikke få et kompetent overblik over standarden.  Og uden overblik, har du ikke en chance for at strukturere din implementering fornuftigt.

Sekstusinde sider er som sagt omkring en halv hyldemeter og det er for meget, uanset hvad det specificerer.

Mht om der er brug for OOXML, det mener jeg ikke der er.  Vi har standardiseret et dokumentformat, det er nok.  Hvad skulle værdien være af at have to formater ?  Hvor megen glæde havde ATM af at have to AAL formater ?  Hvor meget gavnede det OSI at have 3 netværks og fire transport formater ?  Hvor meget glæde havde vi af at have wordperfect og word filformater ?  Svaret er: negativ glæde.

Vi skal have et format, beskrevet kompetent i en læselig standard af rimelig længde (dvs ikke større end en stor lærebog).  ODF opfylder disse krav, OOXML gør ikke.

ECMA har aldrig været en kompetent standardiserings organisation, det har været et "HAHA VI KOM FØRST!" stempel for leverandører så de kunne diktere markedet for deres produkter.

Jeg mener det er helt forkert at ECMA har fast-track rettigheder overhovedet og specielt for sådan et misfoster som Microsofts "vi er også gået over til XML" format, er fast-track helt forkert.

Poul-Henning

Tak til Poul-Henning for at have taget fat på at kommentere Renés blogindlæg. Da jeg selv læste mig igennem tågesnakken første gang, må jeg indrømme at jeg havde svært ved at beslutte mig for hvor jeg skulle begynde, fortsætte og ende med tilrettevisningen af Renés jeremiade af "jeg kan ikke se", "jeg kan ikke finde" og "jeg kan ikke forstå".

Men OK René, når nu Poul-Henning har taget fat, så vil jeg gerne fortsætte:

OOXML standardudkastet går ind og redefinerer eksisterende, gennemarbejdede og bredt implementerede standarder, fx kalender og datoformater (og en lang række andre områder, som dokumenteret på http://www.grokdoc.net/index.php/EOOXML_objections som René elegant refererer til og sparker ud efter uden at linke til det, så en anden læser kan få syn for sagen).

Når et standardforslag er i uoverensstemmelse med andre eksisterende standarder må uoverensstemmelserne dokumenteres og i så vidt omfang som muligt elimineres.

OOXML er tilsyneladende et usædvanligt uskønt eksempel på total ignorance overfor eksisterende standarder. At få OOXMLforslaget arbejdet igennem så det kommer i overensstemmelse med eksisterende ISOstandarder vil være et overordentligt stort arbejde, eftersom det element tilsyneladende har været totalt ignoreret under udarbejdelsen af forslaget. Derfor er det reelt at spørge sig selv om det virkelig er værd at binde kræfter i at reparere på Microsofts (undskyld: ECMAs) makværk, når der nu findes en gennemarbejdet, velbeskrevet dokumentstandard: ODF.

Ærlig talt, René, synes du virkelig man behøver at tage et standardforslag alvorligt når det går ind og ændrer fundamentalt på vores kalendersystem ved at definere året 1900 som skudår? Hvis OOXMLforslaget går igennem så skal vi til at ændre begrebet "efter vor tidsregning" til "efter OOXML".

Med den holdning til referencerammer som noget man retter til efter behag, så vil jeg da foreslå at man som noget af det første beriger OOXMLstandardforslaget med bemærkninger om at "jorden er flad", "jorden er universets centrum" - og hvad med lidt om at "børn er noget som kommer med storken".

Hvad siger en Microsoftarkitekturevangelist til den udlægning af evangeliet?

Thomas

Nå, René, du er ikke sikker på hvad jeg mener med at uoverensstemmelser i standarder bør elimineres.

Det kan være at et eksempel kan oplyse dunkelheden: kan du forestille dig hvad der vil ske hvis man ændrede specifikationerne for det udvendige gevind på bolte, uden samtidig at ændre de tilsvarende specifikationer for det indvendige gevind på møtrikker?

(Inter)operabiliteten går fløjten. Og ja, jeg ved godt at du som evangelist ikke behøver forholde sig til nogen form for realiteter, men blot skal lovsynge helligdommen, men selv en evangelist må kunne se at dette er en situation som ikke er værd at stræbe efter.

OK, og hvad Microsofts sære forhold til den gregorianske kalender angår kan jeg henvise dig til John Walkers glimrende gennemgang på URL http://www.fourmilab.ch/documents/calendar/ (scroll ned til overskriften "Excel Serial Day Number"). Jeg tillader mig at citere et uddrag af John Walkers eksegese nedenfor - men klik over og læs det hele, for den samlede historie er værre end selv en kanoniseret evangelist kan bortevangelisere (selvom du gør et forkølet forsøg  ved at omtale fejlen ikke som en fejl, men som en "fejl"). Beklager René - her hjælper det end ikke at påkalde sig forstærkninger fra ærkeengle: den gregorianske kalender er indført ved paveligt dekret ;-)

Thomas

---------%<------- klip -----------

Citat fra John Walker på URL http://www.fourmilab.ch/documents/calendar/

You'd be entitled to think, therefore, that conversion back and forth between PC Excel serial values and Julian day numbers would simply be a matter of adding or subtracting the Julian day number of December 31, 1899 (since the PC Excel days are numbered from 1). But this is a Microsoft calendar, remember, so one must first look to make sure it doesn't contain one of those bonehead blunders characteristic of Microsoft. As is usually the case, one doesn't have to look very far. If you have a copy of PC Excel, fire it up, format a cell as containing a date, and type 60 into it: out pops "February 29, 1900". News apparently travels very slowly from Rome to Redmond--ever since Pope Gregory revised the calendar in 1582, years divisible by 100 have not been leap years, and consequently the year 1900 contained no February 29th. Due to this morsel of information having been lost somewhere between the Holy See and the Infernal Seattle monopoly, all Excel day numbers for days subsequent to February 28th, 1900 are one day greater than the actual day count from January 1, 1900. Further, note that any computation of the number of days in a period which begins in January or February 1900 and ends in a subsequent month will be off by one--the day count will be one greater than the actual number of days elapsed.

Rene,

Du har tydeligvis aldrig fået smidt en specifikation og en deadline på bordet, har du ?

Når jeg læser ODF og ser en henvisning til SVG, så siger jeg "FEDT!"

Det betyder nemlig at jeg kan tage et standard SVG bibliotek og så er den del af opgaven partitioneret, isoleret og overstået.

Hvis der efterfølgende er fejl i SVG håndtering, så er det kun SVG biblioteket jeg skal kigge på.

Og uanset hvor mange mand man sætter på at implementere et projekt, så bør de alle have læst hele specifikationen på et eller andet tidspunkt, ellers får du bare interfacefejl imellem deres kode, eller dumme designbeslutninger i de forskellige dele.

Mht flere standarder, så er du helt ude i hampen:

Du er imod vidreudvikling af ODF (som om nogen tror M$ ikke vil vidreudvikle OOXML ?) men du er for vidreudvikling af 802.11 ?

Tag lige og forklar mig hvad forskellen er ?

Jeg er ked af at sige det Rene, men jeg har ingen respekt for din viden om softwareudvikling og jeg har mindre og mindre respekt for dine evner som PR-bunny:  dit spind hænger i ål.

Jeg synes du skal tage og læse Frederick P. Brooks klassiske "The Mythical Man-Month" for at lære noget om projektstyring i software projekter.

Poul-Henning

Jeg vil slutte her med at notere mig, at du er ansat og betalt af Microsoft for at debatere med en bestemt mening.

Derfor har ingen af os en jordisk chance for at få dig til at ændre mening, eller for den sags skyld indrømme når vores argumenter er de bedste.

Derfor kan jeg tillade mig at stoppe her, uden at kommentere dit seneste vås, der vil nemlig altid være mere hvor det kommer fra.

Personligt mener jeg at betalt FUD burde straffes hårdt, for sandheden har det hårdt nok uden også at blive angrebet af højtebetalte, målsøgende lystløgneres precisionsvås.

Men jeg må stille mig tilfreds med, at have skudt denne portion vås ned, velvidende at på mandag bliver du betalt for at fyre noget nyt vås af, mens jeg, og andre der ved hvad vi taler om, bliver betalt for at få computere til at gøre noget produktivt.

Jeg håber du har noget andet end dit job at være stolt af.

Poul-Henning

René

Hvis du ikke forstår hvad interoperabilitet har at gøre med bolte og møtrikkers gevind, så må jeg tilstå at det (her fra min stol) ser ud som om din din abstraktions- og generalisationsevne kan ligge på et helt usædvanligt lille sted. Hvilket næppe er heldigt, din jobfunktion taget i betragtning.

Eller måske SKAL man simpelthen hellere løse problemer på manifesteringsniveauet end på oprindelsesniveauet når man arbejder for Microsoft: måske er brandslukning og spin højere agtet end løsning af det bagvedliggende problem?

Du fremturer så iøvrigt med at omtale Excels kalenderfejl som en "fejl" og er så venlig at videregive din kollega Henriks link til en Microsoft supportside på http://support.microsoft.com/kb/214326

Det  var vældig interessant læsning: Microsoft benytter den side til at snakke udenom sagens kerne ved at argumentere for at Excels WEEKDAYfunktion har en fejl med modsat fortegn.

Det betyder at man får den korrekte ugedag udleveret hvis man kalder den INkorrekte dagsnummerfunktion - hvis man altså ikke lige beder om ugedage før 1. marts 1900.

OK, René: hvorfor fa'en retter I så ikke BEGGE fejlene?

Teksten på supportsiden er rent spin: I (eller de af jeres kolleger som har skrevet den tekst) får det til at se ud som om at det eneste problem med "business as usual" er at WEEKDAY returnerer en gal ugedag for datoer FØR 1. marts 1900.

Det VIRKELIGE problem er at alle datoer FRA OG MED 1. marts 1900 er udstyret med et forkert dagsnummer.

At kalde 1900 for et skudår er en fejl - ikke en "fejl", hvad interoperabilitet angår. Der er mange halvgode og helsløje grunde til ikke at have rettet fejlen FØR - men at fastholde den når man alligevel skal til at indføre en helt NY filformatstandard, det er godt nok tåbeligt.

Men for nu at vende tilbage til dit oprindelige blogindlæg, så kan jeg  efterhånden godt forstå hvis du føler trang til at forsøge at sløre problemerne med OOXML for dig selv: det må være frustrerende at arbejde i en teknisk funktion for Microsoft for tiden - forslaget til ISOstandardisering af OOXML har jo gjort firmaet grundigt til grin i hele den tekniske verden - og her hjælper evangelisering og newspeak ikke på situationen (tværtimod).

De herrer Robertson og Paolis flæberi på URL http://www.microsoft.com/interop/letters/choice.mspx har om muligt gjort situationen endnu værre - Microsoft er nu uudsletteligt stemplet som det ynkelige tudefjæs som hellere vil råbe "øv - de andre driller" end bruge kræfterne på at rette egne fejl.

Dine egne opremsninger af alt det du "ikke kan se", "ikke kan finde" og "ikke kan forstå" er egentlig også mest med til at understrege det billede som langsomt er ved at tegne sig: Grunden til at OOXML-standardforslaget tager sig så ynkeligt ud er måske slet ikke at MS er et "evil empire" (som mange ellers var villige til at tro).

Grunden er måske at MS ikke MAGTER at gøre det bedre. Eller sagt lidt mere lige ud af posen: problemet er måske simpelthen at MS' mangler udsyn og tekniske kompetencer som rækker bare marginalt ud over selskabets egne produkter.

Jeg håber det ikke - men det er det billede der står tydeligst gennem spintågerne.

Iøvrigt vil jeg, efter at have prøvet at kommunikere med dig, tilslutte mig Poul-Hennings bemærkninger om det nytteløse i at forsøge at få saglige argumenter til at trænge ind hos en corporate blogger: du SKAL jo, uagtet hvor meningsløst det er, fremture med firmaets spin. Ikke bare fordi det er dit job: du er vel desværre ovenikøbet nødt til at TRO på det evangelium, hvis du skal kunne se dig selv i øjnene. Men det er jo selvfølgelig DIT problem. Du har forhåbentlig selv valgt!