Oh nee! Niet alles in XML!
Microsoft heeft aangekondigd dat in de komende versie van Office, Office 12, alle bestandsformaten standaard XML zullen zijn. Om geen problemen op te leveren met bestaande versies van Office krijgen de bestandsnamen een andere extensie. Voor sommigen zal dit nieuws als muziek in de oren klinken, omdat daarmee de weg open staat om Office documenten echt goed te delen met andere paketten. De XML-schema's voor de formaten zijn/zullen publiek beschikbaar zijn onder een gratis licentie.
Wat is hier niet goed aan?
Mijn ervaring met Word XML en Excel XML is verre van positief. Vooral de wat grotere Excel bestanden leveren een heeeeel groot XML bestand op. Zo groot dat Windows Explorer over z'n nek gaat bij het nagaan wat voor icoontje getoond moet worden bij het bestand!
Nu zegt Microsoft weliswaar dat ze het op gaan slaan in een "industry standard" compressie formaat (lees: zip), maar dan nog heb ik zo m'n twijfel bij wat dit doet voor de performance gezien mijn eerdere ervaringen. Gezien ik betrokken ben bij een applicatie waarin dit, mits het goed werkt, een geweldige oplossing zou zijn, ga ik dit nauwlettend in de gaten houden.
Het staat of valt in elk geval met de manier waarop de compressie werkt. Er is wat dat betreft niets mis met apllicatie specifieke formaten die weinig ruimte innemen. In tegendeel, dat is ook waarom er niets mis is met een relationele database. Alleen in specifieke gevallen wil je daar echt XML in opslaan zoals SQL Server 2005 toestaat. Dat wordt vast een van de meest verkeerd gebruikte onderdelen van SQL 2005 (samen met de mogelijkheid om .NET code in een stored proc te gebruiken). Ik begrijp de push naar XML wel vanuit een comatibiliteitoverweging, maar je kunt je afvragen of alles wel XML moet wezen. Mensen die weten dat ik een boek over XSLT geschreven heb, en een aantal jaren in de community bekend stond als "The XML Guy" zijn misschien verrast door mijn negatieve houding. Laat me duidelijk zijn: XML is een geweldige technologie. Het is echter nog niet echt geschikt voor hele grote data bestanden, omdat het relatief langzaam te parsen is.
Wat is hier niet goed aan?
Mijn ervaring met Word XML en Excel XML is verre van positief. Vooral de wat grotere Excel bestanden leveren een heeeeel groot XML bestand op. Zo groot dat Windows Explorer over z'n nek gaat bij het nagaan wat voor icoontje getoond moet worden bij het bestand!
Nu zegt Microsoft weliswaar dat ze het op gaan slaan in een "industry standard" compressie formaat (lees: zip), maar dan nog heb ik zo m'n twijfel bij wat dit doet voor de performance gezien mijn eerdere ervaringen. Gezien ik betrokken ben bij een applicatie waarin dit, mits het goed werkt, een geweldige oplossing zou zijn, ga ik dit nauwlettend in de gaten houden.
Het staat of valt in elk geval met de manier waarop de compressie werkt. Er is wat dat betreft niets mis met apllicatie specifieke formaten die weinig ruimte innemen. In tegendeel, dat is ook waarom er niets mis is met een relationele database. Alleen in specifieke gevallen wil je daar echt XML in opslaan zoals SQL Server 2005 toestaat. Dat wordt vast een van de meest verkeerd gebruikte onderdelen van SQL 2005 (samen met de mogelijkheid om .NET code in een stored proc te gebruiken). Ik begrijp de push naar XML wel vanuit een comatibiliteitoverweging, maar je kunt je afvragen of alles wel XML moet wezen. Mensen die weten dat ik een boek over XSLT geschreven heb, en een aantal jaren in de community bekend stond als "The XML Guy" zijn misschien verrast door mijn negatieve houding. Laat me duidelijk zijn: XML is een geweldige technologie. Het is echter nog niet echt geschikt voor hele grote data bestanden, omdat het relatief langzaam te parsen is.
posted by Michiel van Otegem at
Thursday, June 02, 2005
4 Comments:
Dat is zeker waar. Het idee an sich is ook niet slecht. Vooral in server-sided scenario's is het kunnen genereren van een bestand met XML heel handig. Onder normale omstandigheden werkt dat prima. Waar het mij vooral om gaat zijn de meer extreme gevallen. Die kunnen nu met Excel-native wel, maar met Excel XML niet.
By
Michiel van Otegem, at 02 June, 2005 23:55
Het zou me niet verbazen als Access in Office 13 een legacy product is. SQL Express met Visual Studio Express werkt bijna net zo makkelijk en is minstens zo goed.
By
Michiel van Otegem, at 03 June, 2005 22:37
Saber, het XML-formaat van Excel neerleggen bij de W3C gaat wel heel ver. Vooral als je bedenkt dat Microsoft de feature-set van Excel nog steeds uitbreid. Microsoft is echt niet zo gek om de voortgang van Excel te laten bepalen door de W3C. We weten allemaal hoe snel de W3C is met het vernieuwen van standaarden (NOT!). Dat de WS-* specs niet (meer) bij de W3C ontwikkkeld worden is omdat de W3C een ongelooflijk bureaucratish geval is. Ik weet niet hoe lang ze nu al roepen dat de XQuery spec "bijna" klaar is, en nog steeds is het geval er niet.
Ik heb ooit een gezegd (en geschreven) dat XML een holistisch of holografisch data model is. Het is in principe in staat om iedere data structuur die we kennen, gestructureerd of juist niet, te bevatten. Met XSLT kunnen we vervolgens de data zo manipuleren dat we iedere data structuur terug kunnen krijgen. Je hoort mij ook niet zeggen dat je Excel niet in XML op kunt slaan, ik zet alleen zware vraagtekens bij de gedachte dat dit het primaire formaat moet zijn.
Wat betreft het formaat... dat kan inderdaad beter. Naar ik begrepen heb is het ook behoorlijk anders dan het huidige formaat, maar met zekerheid kan ik dat niet zeggen.
Bedankt voor de tip... iedereen kan nu commentaar toevoegen.
By
Michiel van Otegem, at 06 June, 2005 21:36
Er is inderdaad wel iets dat niet werkt in Excel XML (in Office 2003): Charts. Maar waar ik eigenlijk op doelde is dat het praktisch niet mogelijk is. Ik werk in een omgeving waarin de Excel XML bestanden nog wel eens 1 GB+ kunnen zijn, en dan gaat de zaak helemaal over z'n nek. Excel XML is dan gewoon onbruikbaar, "kan niet" dus.
Ik ben niet overtuigd dat het onder beheer brengen van documentformaten bij een (bureaucratische) organisatie altijd voordelig is. Zeker niet voor formaten die eigenlijk bij een specifieke applicatie horen.
By
Michiel van Otegem, at 07 June, 2005 15:19
Post a Comment
<< Home