Hoofdcategorieën
Device Settings

Microsoft Office 11 gebruikt XML bestandsformaat

Door Wouter Tinus, zondag 18 augustus 2002 20:41
Bron: WinInformant, views: 933

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:

Office 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.
Volgende 20:52 Intern verkeer ZeelandNet niet meer onbeperkt
Vorige 20:22 Klacht tegen Intel ingediend vanwege 'megahertz-hype'
Advertentie

Reacties

«  1  2  »

Dit zou perfect zijn voor de open-source community.

Ookal is het er niet voor bedoelt het is wel handig natuurlijk.
Geen geklooi meer etc.

Nou wat Office 11 zal echt wel de ondersteuning van de oudere formaten blijven houden.
En dat is nou net waar de Open Source community nou de problemen mee hebben.
Ze zullen dus wel de nieuwste docu's perfect kunnen openen maar niet de oude.
En elk bedrijf zal niet zomaar zeggen van kom laten we nu met z'n alle Office 11 gaan draaien want dat zal een bedrijf heel wat centjes kosten.
(en zeker met dat nieuwe licentie gebeuren.)

Nee, maar je hebt maar 1x Office 11 nodig om alle documenten naat XML om te zetten (want MS zorgt wel voor een 100% werkende conversie) en die XML kan je dan wel in gratis pakketen zoals OpenOffice gaan openen :)

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 :)

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

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 :?

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

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

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]

:P 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...

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.

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.


LOL, te laat! Je bent de vierde :+

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

Eigenlijk: Kan Office je PHP output begrijpen...

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..

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!

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!

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.

De verandering is echter niet gemaakt om de open source community tegemoet te komen, maar om integratie met .NET web services makkelijker te maken

Is het niet de grote bedoeling dat .NET en Open Source op vrijwel hetzelfde neerkomen?

Cross-platform is heel iets anders dan open source :)
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 20:52 Intern verkeer ZeelandNet niet meer onbeperkt
Vorige 20:22 Klacht tegen Intel ingediend vanwege 'megahertz-hype'
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011