Bedrijfsleven toont interesse in XML-features Office 2003

Hoewel het pakket pas over enkele maanden op de markt komt, krijgt Microsoft al van verschillende kanten positief commentaar op Office 2003. Met name de XML-features worden goed ontvangen. Met behulp van twee sites ondersteunt het bedrijf derde partijen - waaronder directe concurrenten op het gebied van CRM en content management - bij het integreren van Office 2003 met hun producten. Van ondere andere HP, Xerox, Electronic Data Systems, J.D. Edwards en Factiva is bekend dat ze met de XML-formaten van Office 2003 aan de slag zijn gegaan.

Sommige mensen twijfelen echter nog steeds aan de mate van openheid. Paul DeGroot van onderzoeksbureau Directions denkt dat het zonder hulp van Microsoft nog steeds (te) lastig zal zijn om de door Office 2003 gemaakte XML-documenten volledig correct te interpreteren. Naar verwachting volstaat ieder standaard XML-parser-component wel voor het uitlezen van de elementen en attributen, maar voor daar iets nuttigs mee gedaan kan worden moet wel precies bekend zijn hoe het document is gestructureerd en welke waardes zich naar welke eigenschappen laten vertalen. De partners en Microsoft zelf zijn uiteraard wel positief:

"We've been involved in the development of XML because that's in the best interest of the whole industry," said Dan Leach, Microsoft's lead product manager for Office System. "I would hope that our leadership in the industry is viewed as a positive thing...and maybe some of the preconceived notions people might have about Microsoft are really challenged, when they see that we take very seriously our leadership position."

Reacties (26)

[voodooless]

Hoezo wordt er weer eens de indruk gewekt alsof Mircrosoft de eertste en enigste is die XML gebruikt als een standaard voor documenten. OpenOffice en companen doen dit al lang!

De vrees in de tweede paragraaf is zeer terecht is. Van de initieele openheid zal waarschijnlijk weinig overblijven, als er geen open standaard is voor het renderen van deze XML documenten.

[Verwijderd]

De 1.1RC van OOo zegt in de release notes zelfs:
- an example XSLT filter for Office 2003 XML format

[Verwijderd]

Ik heb het zelf ook al geprobeerd. Ik had het document niet zo ingewikkeld verwacht todat ik het "labyrint" aan nodes en attributes zag. Geheel nietszeggend op het eerste gezicht.

Met diverse exports staan nodes en attributen weer op hele andere posities, en ook de benaming is nietszeggend.

[Verwijderd]

Het mag misschien voor het menselijk oog onleesbaar en ongegrijpelijk zijn maar gelukkig hebben we daar computers voor omdat op te lossen.
Maar inderdaad moeten die er ook een touw aan vast kunnen knopen. En wellicht zal dit wel even duren om het 'door' te krijgen. Hopelijk dat MS wat dat betreft meewerkt. Desnoods wordt het een projectje.

Toch al is het een interessant project want op die manier is het al mogelijk om deze documenten als XML in database op te slaan. Die stap is dan zowieso al mogelijk. Bij heel veel databases is dat al mogelijk trouwens. En die stappen daarna blijven toch altijd wel in ontwikkeling, net zoals MS die XML vast wel inhoudelijk gaat wijzigen en compatibiliteit een issue kan worden (leer mij MS en programmeren kennen). Maar dan 'knal' je er eerst een XSLT over om het weer compatible te maken. (een van de handige features van XML) Of gewoon om de 'rotzooi' eruit te filteren.
Maar als je dan eenmaal die documenten in XML in je database hebt kun je leuke dingen gaan doen. Ideaal om wat structuur aan te brengen wat nu toch al een redelijk gedoe is en bijna iedereen op dat vlak wel z'n eigen standaarden heeft. Hopelijk dat dit dan meehelpt naar wat meer uniformiteit.

Maar wat nu ook veel makkelijker geworden is om bijv OpenOffice ed makkelijker mee te laten groeien met de veranderwoede van MS. Zodat je daarmee ook makkelijker je documenten mee kunt aanpassen etc.

En dan wordt het bijv sleuren en pleuren van je browser naar je office documenten veel makkelijker gemaakt en heb je geen last dat er HTML code in de weg gaat zitten en kun je het net zo makkelijk weer terug slepen naar je browser en die er ook zonder problemen mee om kan gaan.
(het is maar een voorbeeldje hoor, maar probeer het maar eens met bijv excel en asp pagina's zonder voorgebakken componenten)

[Goodielover]

Ik ben vooral benieuw naar de mogelijkheid om een eigen DTD aan te bieden, zodat je Word als een echte XML editor kunt gaan gebruiken a la Epic.
Ik heb begrepen dat de pro versie wel die mogelijkheid zou moeten bieden, maar meer zekerheid heb ik er ook niet over, laat staan ervaringen.

[edit: typo's]

[Woy]

Dit is volgens mij inderdaad wel een optie. Ik ben op een ofice 2003 seminar geweest bij microsoft en hier lieten ze wat dingetjes zien met xml. Er zijn 2 manieren van xml gebruiken in office. Je kan gebruik maken van Office Xml. Dit zijn documenten die ook opmaak hebben en deze zitten zeer complex in elkaar en ik vraag me inderdaad ook af hoe open microsoft over de definitie hiervan zal zijn. Maar er is ook de optie om data te binden vanuit xml en vanuit je doc ( word, excel en waarschijnlijk ook andere zoals Infopath ) weer terug naar xml. Dit werkt zover als ik het kon zeer flexibel en je kon inderdaad ook zelf je dtd opgeven

[arnob]

HP, Xerox, Electronic Data Systems, J.D. Edwards en Factiva is bekend dat ze met de XML-formaten van Office 2003 aan de slag zijn gegaan

Ik snap het niet. Die bedrijven maken toch geen tekstverwerkers? CRM pakketten hoeven documenten toch niet te snappen? Als ze deze maar kunnen koppelen of als object op kunnen slaan, dat lijkt me genoeg.

Om een CRM pakket een tekst te laten doorzoeken lijkt XML parsing me overkill. MS Word als object gebruikend kunnen ze gewoon door de tekst struinen. Gebruikers gaan toch geen velden markeren in tekst? (databasing in een tekstverwerker is niet veel soeps, in Excel is niet veel beter)

[Brahiewahiewa]

Ik snap het niet.

't Idee is dat je MS Word als front-end voor die CRM applicaties kunt gaan gebruiken. Al die twiekertjes hier denken weer niet verder dan het schrijven van een briefje of het tikken van een memootje. Maar waar het om gaat is dat je documentbeheer rechtstreeks gekoppeld wordt aan je CRM applicatie en dan heb je een ijzersterke combinatie waar OpenOffice een puntje aan kan zuigen

[NoControl]

[maybe_too_optimistic]Ik vind dit gewoonweg prachtig. Goed nieuws. Microsoft volgt de rest van de Office-pakketen naar een open formaat. Misschien is dit een begin voor een standaardformaat voor documenten, spreadsheets, etc. Immers, XML kan (mits een beetje doordachte zorg) uitgebreid worden zonder compatibiliteit te verliezen.[/maybe_too_optimistic]
Aan de andere kant, zo makkelijk zal het niet worden om deze nieuwe formaten te begrijpen. Zoals al gezegd werd is het helemaal niet self-explanatory. En heb je al eens gekeken naar wat voor junk Word erbijzet als je je document uitvoert naar HTML? Ziet er niet uit, terwijl HTML ook een standaard is

[Verwijderd]

Je zegt het dus al zelf, die junkcode die Word erin zet is er bijna niet uit te halen. Converteer eens een excellblad met plaatjes naar HTML en bekijk het in IE voor de MAC. Geen enkel plaatje wordt weergegeven omdat de code niet aan de standaard voldoet.

Aan de andere kant is XML zo doorzichtig en flexibel dat je volgens mij vrij snel een passend MS-XML filter kunt schrijven. Zonder dat je MS dat rechten voor hoeft te betalen.

Kijk trouwens eens naar pdf-bestanden ook daar zijn al third-party solutions voor.

[RobT]

Ik heb 1 brandende vraag: zal Office 2003 in staat zijn om de OpenOffice.org xml documenten te lezen?

Want dan is office2003 wel degelijk positief; kan je lekker alles in OOo doen, en iedereen kan het altijd lezen!

Kunnen we met zijn allen over op OOo zonder gezeur van compatibiliteit.

Maar ik vermoed dat ik hier te optimistisch ben... (past ook helemaal niet bij me, in relatie met iets van MS.... )

[Verwijderd]

Nee dat kan niet, maar OO kan straks wel Office 2003 XML herkennen en omzetten naar de OO XML.

[Verwijderd]

PDF is een van de lastige formaten. Er is geen enkele partij die PDF documenten op de juiste manier zonder fouten kan parsen.

Zelfs Adobe krijgt het niet 100% voor elkaar om PDF altijd goed gerenderd te krijgen. Dat is best knap niet?

[Verwijderd]

Het punt zit hem niet in de XML. Iedereen die het principe achter XML kent kan XML lezen (XSL, XSLT, DTD's en Schema's zijn een ander verhaal).

Waar Microsoft het ons nu hier moeilijk maakt, is om heel vreemde benamingen, afkortingen en volgordes te gebruiken in hun beschrijving van de gegevens.

Bepaalde zaken kun je wel filteren, zoals line breaks, font stijlen etc. want je legt het originele document ernaast en repeterende code valt zo op.

Waar het moeilijk wordt, is de wijze, waarop de afzonderlijke nodes als beschreven in het xml bestand, worden samengevoegd tot een voor de tiepmiep leesbaar bestand.

Ik heb hier een Hello World voorbeeld van de XML, die voortkomt uit een simpel .doc bestand:

[Admin break - gigantische layout f*ckup]

[Verwijderd]

wel grappig zo vaak als ze gebruiken.

Heeft het iets te maken met de code die ze gebruiken om het andere ontwikkelaars het moelijk te maken om een compatible programma ta maken?

[Johnny]

Die doet meer dan "Hello Word!" hoor. Wel is meteen al weer te zien dat er nog even ranzog wordt omgegaan met XML als met HTML in MS Word 97, iedere keer opnieuw de taal defineren (lang="NL") is onnodig en maakt het document echt niet leesbaarder.

[Wouter Tinus]

Waarom zou dat niet nodig zijn? Word stelt je nu eenmaal in staat om met documenten te werken die in meerdere talen zijn opgesteld, waar bijvoorbeeld de spellchecker rekening mee moet houden. Deze informatie wordt in het .doc-formaat mee opgeslagen, en dus moet hij ook in het xml-formaat komen te zitten. Zouden ze dat niet doen dan was het simpelweg niet compleet. Het leesbaarheidsargument slaat nergens op, want het is echt niet de bedoeling dat je die rauwe xml gaat zitten doorlezen. Voor een computer (parser) maakt het niets uit hoevaak een tag voorkomt; de performance van die dingen is zeer goed.

[Verwijderd]

Die performance ben ik een beetje bang voor eerlijk gezegd.
Een 'normaal' word document is al een paar MB groot en als je het hierarchisch ook nog ingewikkeld maakt (daar mag je wel vanuit gaan, want je moet met van alles en nog wat rekening houden) dan kan het parsen nog wel eens tricky worden.
Wellicht dat ze zelfs speciale parsers nodig hebben (of tenminste geoptimaliseerde parsers) als het nog grotere documenten worden. Een beetje DOM parser krijgt het al lekker druk als je dat soort documenten gaat parsen hoor.
Gelukkig zullen de systeemeisen voor Office XML vast wel hoog genoeg zijn om hier rekening mee te houden.

[Wouter Tinus]

Een 'normaal' word document is al een paar MB groot en als je het hierarchisch ook nog ingewikkeld maakt (daar mag je wel vanuit gaan, want je moet met van alles en nog wat rekening houden) dan kan het parsen nog wel eens tricky worden.

Ik denk dat het veilig is om er vanuit te gaan dat het .doc-formaat intern ook als een hiërarchische boom is opgebouwd met attributen en elementen, alleen dan op een 'onbegrijpelijke' manier opgeslagen. Tenzij .doc standaard gecomprimeerd wordt verwacht ik niet dat een .doc.xml heel veel groter zal zijn. "Een paar MB" voor een normaal document vind ik trouwens erg knap, ik heb documenten van ruim 100 pagina's gemaakt met heel veel tabellen, stijlen en zelfs een aantal plaatjes, die ongeveer op 1MB uitkwamen. Een normaal document, zoals een brief, nieuwsbericht of offerte, zal niet vaak zo groot zijn.

Wellicht dat ze zelfs speciale parsers nodig hebben (of tenminste geoptimaliseerde parsers) als het nog grotere documenten worden. Een beetje DOM parser krijgt het al lekker druk als je dat soort documenten gaat parsen hoor.

Zal ook voornamelijk afhangen van de parser die gebruikt wordt, maar bijvoorbeeld MSXML 4.0 kan op een moderne pc makkelijk omgaan met een document van vijf of tien megabyte, waarschijnlijk nog wel meer. Afhankelijk van wat voor capriolen je er mee uit wil gaan halen (dus eigenlijk: hoe efficiënt de programmeur werkt) is dat heel goed te doen. Hoe dan ook, als het realtime parsen niet snel genoeg gaat kan natuurlijk ook altijd nog voor gekozen worden om de data in een andere (simpelere) structuur in het geheugen te laden en daar de bewerkingen op uit te voeren. XML is immers bedoeld voor overdracht van data, niet om er rechtstreeks in te gaan werken .

[Verwijderd]

Ik ben zelf tijdens mijn stage ook intensief bezig geweest met xml. De nodes en attributen zijn voor elke toepassing apart gemaakt zodat er een logisch geheel ontstaat waardoor de gegeven bruikbaar zijn,

Bart

Student Bedrijfskundige informatica.

[gumkop]

De nodes en attributen zijn voor elke toepassing blablabla gegeven bruikbaar zijn,

Dat is toch met alles de bedoeling ?? Geef eens voorbeelden hoe je makkelijk achter de bedoeling van de MS nodes en attributen kan komen, volgens mij is het namelijk ook zo oncompatible als het maar kan, was er nu maar 1 XML standaard ....

[Aaargh!]

was er nu maar 1 XML standaard ....

Er is maar 1 XML standaard, het probleem zit 'm ook niet in de XML maar in de interpretatie ervan. Als jij een textfile in het grieks krijgt, dan kan je de file wel lezen maar totdat iemand jou grieks leert kan je de betekenis niet achterhalen.

Het vastleggen van deze betekenissen heeft ook geen zin want dan gaat het hele voordeel van XML weg.

[BaronTankhe]

Microsofts schema (xsd) voor hun office documenten zal precies beschrijven hoe een XML office document er uit zal zien..... de vraag is alleen krijgen andere bedrijven toegang tot dat schema.

[LosserNL]

Intensief bezig geweest? Kom op die 2e zin van je kan dan wat beter geformuleerd worden!