Microsoft Office 11 gebruikt XML bestandsformaat

Op WinInformant is een kort bericht te lezen waarin staat dat de opvolger van Office XP - codenaam Office 11, ook wel Office.NET genoemd - XML gaat gebruiken als bestandsformaat. Microsoft breekt hierbij eindelijk met de gesloten formaten van de vorige suites. De verandering is echter niet gemaakt om de open source community tegemoet te komen, maar om integratie met .NET web services makkelijker te maken. In de toekomst zal ook de Active Directory op XML gebaseerd worden:

But exposing Office data natively as XML will also give competitors a chance to make their products more interoperable with Office, no doubt leading to future OpenOffice.org and Sun Microsystems' StarOffice products that will finally be 100 percent compatible with Microsoft's offerings. The company says the benefits outweigh the risks, however, and is pressing ahead with what it calls end-to-end experiences that blur the lines between the desktop and server-side services.

Reacties (51)

Ik denk - vrees eigenlijk - dat een aantal mensen hier iets te optimistisch is. Er wordt gemeld dat de nieuwe Office bestanden in XML zal opslaan en meteen jubelt WinInformant dat er dan wel 100%-werkende import- en exportfilters zullen komen. XML is een tekstgebaseerd bestandstype, wat betekent dat je er niet alles in kunt opslaan. Voor de bestanden zal een DTD worden gemaakt, die bepaalt wat elk element van een bestand betekent. Op die manier kan er - zoals in HTML gebeurt - bijvoorbeeld iets als <img src="http://www.microsoft.com/logo.jpg"> worden gebruikt, waarna er in de definitie staat wat de IMG-tag precies inhoudt.

Het is echter niet gezegd dat al deze informatie zo eenvoudig te lezen zal zijn. Momenteel gebruikt bijvoorbeeld KOffice - de Office suite van KDE - een XML-gebaseerd bestandsformaat. Plaatjes worden apart opgeslagen en dan via een soort IMG-tag in het document gelinkt. Het hele boeltje van XML-tekst, plaatjes en extra informatie over het bestand (auteur, revisie) wordt bij elkaar genomen en ingepakt tot een .kwd-bestand. Het is dus niet zo dat je even in Notepad dat bestand kunt openen en dan zien hoe het is opgebouwd: je krijgt dan gewoon binary code te zien. Bij KWord/KOffice is dat geen probleem aangezien het openbaar is hoe je zo'n bestand moet uitpakken, maar Microsoft zou zonder problemen op een zelfde manier het geheel kunnen inpakken en niet bekend maken hoe het uit te pakken (toegang zou via een library kunnen gaan). Sterker nog, ik weet wel zeker dat ze het in gaan pakken, aangezien pure XML veel te inefficiënt is om zonder compressie op te slaan en te versturen. Daarnaast zit je nog met losse extra informatie. De grote vraag is op welke manier ze het in gaan pakken. Ze zouden een compressie kunnen ontwikkelen en geld vragen voor de decompressor, dat is een geheel legale manier die hen nog geld oplevert ook. Volgens de huidige Amerikaanse wetgeving zou het verboden zijn om dan een eigen decompressor te schrijven en dat is niet alleen een loos stuk wetboek. Er zijn al mensen aangeklaagd en vervolgd wegens het omzeilen van een leesbeveiliging van Adobe op hun eBook-formaat. Ik hoop van ganser harte dat Microsoft niet besluit die weg in te slaan en echt kiest voor de openheid waarop het internet tot nog toe gebaseerd is, maar ik ben er nog niet helemaal gerust op.

Wat ook mogelijk is, is dat je zoiets krijgt:

<content type='Microsoft Word 11'>
*FIEJG)G)*_G*&)*)_&#UJJKNKLJDLFHJ)*&)_
*&E)*&EWR(_*_(*_*I_U)(#@(KDFJK:JDFLFJD
</content>

Dan kun je ook zeggen dat je een XML document hebt, maar dat wil nog niet meteen zeggen dat de inhoud ten alle tijden transparant is. Ik hoop dat ze dat wel gaan doen. Wat ze ook zouden kunnen doen is er een NDA aanhangen of zeggen dat er geen GPL implementaties van gemaakt mogen worden (zoals van het SMB protocol).

Dus ik ben het met je eens dat we niet allemaal moeten gaan juichen, eerst maar eens afwachten hoe Microsoft het allemaal precies denkt te doen...

Moet je 's doen: een XML-database inladen in Excel. Maakt'ie prachtige kolommen aan met de info erin.
Echt fantastisch, maar je moet niet het boeltje weer weg willen schrijven in Excel...

Dan propt ons vriend Gates er de nodig tags tussen dat het een lieve lust is. Het bestand is bijkans niet meer leesbaar en tenminste 85% in grootte toegenomen.

Maar toch. XML 100% volgens de standaarden of 99% is in ieder geval al beter dan het formaat wat nu gebruikt wordt. Een hele stap vooruit - niet?

Aangezien De Office Suite zo'n beetje door alle grote bedrijven gebruikt gaat worden, zou ik wel kunnen leven met de 'standaard' van MS.

Ik ben niet met je eens dat XML veel te inefficient is om op te slaan. Kijk nu naar de harde schijven van tegenwoordig, die zijn verhoudingsgewijs enorm gegroeid. Een MBtje meer of minder zou niet zo heel erg zijn.

Overigens biedt NTFS de optie om hele directories te comprimeren op OS niveau. De uitwisselmogelijkheden wegen in mijn ogen veel zwaarder dan de grootte van de bestanden.

OpenOffice slaat z'n XML-bestanden zelf op in zipfiles. Ook KOffice doet dat, iirc. De grootte van de bestanden is inderdaad niet relevant t.o.v. de huidige schijfcapaciteit, maar ze is dat zeker wel als het om documenten gaat die je met de mail moet versturen.

Check http://xml.openoffice.org/ voor meer info.

99% XML kan niet. De standaard is hier heel duidelijk in, iets is of 100% XML, of het is iets anders. XML is ook een hele simpele standaard, die je in principe in een half uurtje kunt leren (de syntax dan, de betekenis verschilt per toepassing). Het is veel simpeler dan HTML:

- Alle open-tags een sluit-tag
- Tags zijn case sensitive
- Alle attributen gequote
- Precies één top-level element
- Tags correct genest
- Bovenaan een XML declaratie

Ik ben vast nog wat vergeten, maar hiermee ben je er al bijna!

Dit is een voorbeeld van een goed XML document:

<?xml version="1.0" encoding="ISO-8859-1"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

Het is belangrijk om te beseffen dat XML zelf niets doet. Het is een markup taal. De tags (note, to, from, etc) zijn zelf verzonnen, alleen applicaties die deze tags juist kunnen interpreteren kunnen er iets mee doen. HTML is (bijna) een XML dialect, waarbij de betekenis van de tags (body, h1, img, a, etc) door het W3C en de browserfabrikanten zijn overeengekomen. XHTML is de versie van HTML die helemaal XML compliant is.

Lees meer op http://www.w3schools.com/xml/xml_whatis.asp

Strikt gesproken kan 'xml' (wat een wel erg brede, overal op toepasbare kreet is overigens) wel degelijk blokken binary code bevatten. In principe kunnen ze dus gewoon plaatjes e.d. in de file zetten. Of dat slim is is een ander verhaal.

In ieder geval -en op dat punt ben ik het met je eens- betekent 'xml' zeker niet automatisch een open formaat waarvoor iedereen maar even een converter kan schrijven.

Over OOo-files: die kun je gewoon unzippen, waarna je de losse ingredienten overhoudt.

Volgens de huidige Amerikaanse wetgeving zou het verboden zijn om dan een eigen decompressor te schrijven en dat is niet alleen een loos stuk wetboek.

Ik verwacht niet dat ms zich aan de wet gaat houden.

Nee einstein, hij bedoelt juist dat als MS zijn eigen compressor schrijft, dat jíj (of wie dan ook) dan niet zomaar een decompressor mag schrijven, hier wil MS zich dus juist wél aan de wet houden.

Visio 2002 biedt al de mogelijkheid om je bestanden in XML formaat op te slaan. Plaatjes worden netjes ge-embed in deze bestanden.

Nu komt de adder onder het gras. Microsoft heeft de laatste tijd veel techneuten een gat in de lucht doen springen, om daarna weer in huilen uit te barsten.
Ook dit keer is het raak. De licensievoorwaarden over deze XML bestanden lezen namelijk dat je ze niet in mag lezen door gebruik te maken van third party programma's (zoals PHP bijv.), en dat je ze ook niet mag genereren zonder gebruik te maken van de oorspronkelijke Office programmateur.

Kortom: technisch heb je er alles aan, maar juridisch helemaal niets.

Ik kan me niet voorstellen dat MS patent heeft op een xml-layout. Wie houd me tegen als ik documenten genereer die toevallig dezelfde vorm hebben als die van MS? xml is een open standaard, laat MS maar eens proberen patent te krijgen op een tag.

Ik beweer niet dat we er wel wat aan hebben, maar voor de juridische kant van de zaak ben ik niet zo bang.

De XML layout valt niet onder een MS patent, maar valt gewoon onder copyright. Het gaat er niet om dat je een document op dezelfde manier kan reproduceren of gebruiken, maar of je een document met exact dezelfde structuur gaat reproduceren en/of gebruiken. Die structuur is zo uniek dat Microsoft altijd gelijk krijgt bij een rechter als er betwist word of een third party bedrijf in staat is geweest om een dergelijk data bestand te maken zonder dat deze ooit de structuur heeft afgekeken van een met copyright beschermd programma als MS Office.

Reactie op ajvdvegt:
Je moet het copyright verhaal niet zien vanuit een consumenten perspectief. Het gaat erom dat de programmatuur die jij gebruikt om dit bestand in te lezen copyrights schend als deze dit bestand met een identieke structuur inleest, of met eenzelfde structuur wegschrijft.

Wie houd me tegen als ik documenten genereerd die toevallig dezelfde vorm hebben als die van MS?

Ja, wie houdt me tegen als ik boeken schrijf die toevallig dezelfde vorm of inhoud hebben als een bestaand boek.

Er bestaat toch ook nog zoiets als auteursrecht?

Als ik van iemand een XML bestand krijg heb ik niet hoeven tekenen noch een licentie hoeven lezen. Nemand die me dan verbiedt dat bestand proberen te openen en te lezen.

En dat zal MS ook worst wezen. Heb je wel eens de source van een webpagina bekeken? Spannend he? Een MS-Office XML bestand zal hier veel op lijken, maar dan met zo mogelijk nog saaiere inhoud.

Waar het om gaat is dat Sun of andere grote bedrijven geen programma's mogen maken die de XML bestanden van MS inlezen of wegschrijven. Dat jij een beetje recalcitrant met UltraEdit gaat liggen hobbyen, daar ligt Microsoft niet wakker van.

Ik hoop dat dit auteursrecht verhaal niet waar is. Bronnen?

XML? Geweldig! Denk aan de mogelijkheden die nu relatief eenvoudig bereikbaar zijn:

Gemakkelijk in document/ contentmanagementoplossingen te gebruiken. De attributen kan je immers uitlezen via een xsl stylesheet. .NET, Webservices, etc.... Het is (misschien wel een beetje helaas) waarschijnlijk DE XML-editor die iedereen gaat gebruiken..

nu maar hopen dat ze zich ECHT aan de XML-standaard houden en er niet zo'n potje van maken als Internet Explorer met zijn 'sloppy' HTML. Maar goed, goede ontwikkeling op zich. kan ik straks eindelijk die word-attachments lezen via mijn linux-textmode-email programma zonder eerst helemaal OpenOffice op te starten. ook een erg goede ontwikkeling (zoals eerder al gezegd) voor de opensource community. toppie!

Eens een keer wat anders dan de berichten over Microsoft die de rijen gesloten willen houden !
Mischien niet eens een verkeerde stap ....nou maar eens kijken hoe dat in de praktijk zijn uitwerking heeft !

Dat is 2 jaar geleden al begonnen met de .NET strategie. Die is radicaal doorzichtiger dan wat we van MS gewend zijn. Een 100% windows 95 emulator bestaat nog steeds niet, terwijl een .NET server zonder al te veel moeite nagemaakt kan worden. En dat gebeurt ook al. Zie www.ximian.com/devzone/projects/mono.html

.NET is geen OS, zoals win95, maar een (online) platform waarop applicaties runnen, beetje vergelijkbaar met een java VM.

Moet je wel XML gaan leren, tis tog net iets als HTML of niet?

je hoeft geen xml te leren hoor, dat doet microsoft wel voor je

Office blijkt er gewoon hetzelfde uitzien... Het voordeel is wel dat andere software snel met Office documenten overweg kan, je kan nu bv. makkelijk een app bouwen die naar een bepaald woord zoekt in een "Office" document. Dat is nu heel wat moeilijker.

Als je XML helemaal beheerst kan je vast nog sneller doxumenten opmaken met scriptjes, tools, ...

En je hebt ook geen Office meer nodig om Office documenten te tonen.

Ik vraag me alleen af, hoe worden plaatjes opgeslagen in XML

tsja bijvoorbeeld door het plaatje op te slaan als

<plaatje coding=JPG>
afoi31afafa0g3aeg9et4et78105710
</plaatje>

of iets vergelijkbaars

offtopic:
[quote]

<plaatje coding=JPG>
afoi31afafa0g3aeg9et4et78105710
</plaatje>

[/quote]

grinnik, deze serie letters lijkt mij moeilijk te vertalen naar een plaatje, de o, i, g en t komen niet voor in het hexadecimale (16-tallige) stelsel:

0 = 0
1 = 1
...
9 = 9
A = 10
B = 11
C = 12
D = 13
E = 14
F = 15

Het houdt dus op bij F.
Het voordeel van hexadecimaal is dat het hiermee mogelijk is om precies 4 bits te coderen in één hexadecimaal digit. Dit is voor mensen veel gemakkelijker om mee te werken dan een reeks van enen en nullen. Eén byte is dus 8 bits en twee tekens hexadecimaal. 4 bytes, of een 32 bits DWORD (op x86) is dus precies 8 tekens. FF is dus 15 * 16 + 15 = 255. 3A = 3 * 16 + 10 = 58 enzovoort. Ook levert het werken met hexadecimale reeksen een groot voordeel tegenover decimale reeksen, omdat je bijvoorbeel veel gemakkelijker binaire bewerkingen zoals AND, OR, XOR en NOT kunt doen. Een ander talstelsel is het octale, of acht-tallige stelsel. Hierbij bestaan de 8 en de 9 dus niet! Dit stelsel wordt echter veel minder gebruikt, omdat het maar 3 bits can coderen per digit, zodat je voor een byte 2,666666 digits nodig hebt...Een beetje onhandig...

FYI:
Nog nooit gehoord van MIME encoding en zo?
Ik weet niet hoor, maar een JPG bevat binaire data en XML is een tekstformaat, dus wat roelio daar zegt is perfect mogelijk aangezien ze de data eerst in tekst moeten omzetten...

Hoeft niet zo moeilijk te zijn. Een aantal tags met eigenschappen e.d., en dan iets als:

<image-data>
EB35AE413AAFFE157A33FF .... (hex code)
</image-data>

OpenOffice en StarOffice 6 slaan links op naar plaatjes in het XML document. Ik verwacht dat Microsoft ook zoiets gaat doen. Het zal denk ik gewoon net zo worden als het bestandsformaat van OpenOffice, dus gewoon een grote zip waarin alle files worden opgeslagen.
Dat is veel efficiënter dan alles in 1 grote XML gooien en werkt ook veel makkelijker.

Ehh... daar heb je nou juist die mooie WYSIWYG editor voor... juist ja: MICROSOFT OFFICE

Kan je met PHP etc. tenminste makkelijk office documenten genereren! Prachtig!

Eigenlijk: Kan Office je PHP output begrijpen...

Eindelijk

Dat doet StarOffice al tijden bij mijn weten. Met een beetje mazzel wordt het dan ook een stuk makkelijker om documenten uit office te converteren. Nu gaat dat vaak fout (als er "ingewikkelde" dingen zoals tekstvakken enz. inzitten). Dat is nu eigenlijk nog de enige reden om niet over te stappen op StarOffice, tenminste niet op het kantoor waar ik systeembeheerder ben, aangezien dat toch vrij veel extra geklooi zou opleveren.

Dat doet StarOffice idd al heel lang. Een van de grote voordelen daarvan is dat ze (plain text) zeer makkelijk te comprimeren zijn zodat een opgelagen xml document zeer compact kan worden!

Als ik iets doms zeg dan roep maar, maar is het niet zo dat 90 % van deze wereld al een office versie gebruikt met .doc bestanden en zo. Is het dan ook niet zo dat de meesten gewoon blijven bij hun versie van office zonder over te stappen. Dan is het toch ook zo dat microsoft formaten kan veranderen zoveel als ze willen maar dat het niet zeker is of de grote meerderheid daar aan mee gaat doen. Die blijven gewoon met hun office 97, 2000 of XP werken.

Bij Office 11 zal de meerderheid nog wel als DOC-oudestijl opslaan, maar vanaf bijv 12 moet het wel om gaan slaan... naar dit DOX-formaat (dat lijkt me wel geschikte extensie namelijk )
Beter dan nooit

Ik neem aan dat ze voor embedded images gewoon Base64 encoding gebruiken (en als WMF formaat opslaan), wat de standaard daarvoor is, en niet lopen klooien met externe plaatjes om daar vervolgens naar te linken.

Base64 encoding is een beetje ruimteverspillend he? Zeker voor plaatjes. Niet dat het MS in het verleden heeft tegengehouden, maar ik hoop toch zeer dat ze voor linken kiezen...