Intel brengt library's voor snelle xml-verwerking uit

Intel heeft de Xml Software Suite aangekondigd. Deze verzameling Java-, C- en C++-routines is bedoeld om de performance van de verwerking van xml in met name application servers en soa-software aanzienlijk te versnellen.

Door middel van de bibliotheken is het mogelijk xml-bestanden te parsen of te valideren aan de hand van een vastgesteld schema en er kunnen transformaties mee worden uitgevoerd. Volgens Intel is de software geoptimaliseerd voor de verwerking van xml-bestanden die groter zijn dan 1GB.

De library's zijn ontwikkeld op basis van technologie die Intel ruim twee jaar geleden in handen heeft gekregen door de overname van Sarvega. De software is volledig compatibel met een aantal xml-standaarden, zoals de W3C-standaarden Xml 1.0, Namespaces in Xml 1.0, Xpath 1.0, Xslt 1.0 en DOM Level 2 Core, Sax 2.0.2 en Jaxp 1.3/1.4. De ondersteuning voor W3C's DOM Level 3 Core is slechts gedeeltelijk aanwezig.

Het voornaamste voordeel van deze Intel-software ten opzichte van hardwarematige xml-versnellers is de volledige support voor de Jaxp-standaard, waardoor er vrijwel zonder aanpassingen in Java-code gebruik van gemaakt kan worden. Voor C- en C++-gebruikers gaat dit voordeel echter niet op; daarnaast is de ondersteuning voor het .Net-framework afwezig.

Het is de bedoeling dat de software de komende maanden verder uitgebreid wordt. Zo zal in 2008 een Xml Encryption-uitbreiding verschijnen, waarmee er volledige ondersteuning voor de WS-Security-stack zal worden aangebracht. De Xml Software Suite 1.0 kan direct bij Intel worden aangeschaft. De editie voor ontwikkelaars kost 499 dollar en de versie voor productiemachines moet 4999 dollar kosten.

Reacties (47)

[mddd]

Het zal wel aan mij liggen, maar als je XML bestanden hebt die groter zijn dan 1 GB, doe je dan niet ergens iets verkeerd? XML is niet echt de meest ruimte-efficiente manier om gegevens op te slaan en ook niet een erg snelle manier om data op te zoeken. Maar er is vast wel iemand die mij kan uitleggen voor welke toepassingen dergelijke XML bestanden ontzettend nuttig zijn.

[Bobco]

XML is inderdaad nogal bloated. Veel ontwikkelteams hebben het idee dat als een beetje XML goed is, heel veel XML nog beter moet zijn. Het ligt denk ik een beetje aan de tooling die beschikbaar is. Voorhet parsen van XML zijn er stapels tools (zoals deze van Intel) te vinden. Deze doen hun werk goed en er is over het algemeen gemakkelijk mee te ontwikkelen.

Het schrijven van een parser voor weer een ander formaat is best wel wat werk, en XML kan voor een heleboel zaken een oplossing bieden. Een XML file van meer dan 1 GB is natuurlijk absurd, dat soort hoeveelheden data komt denk ik alleen voort uit multimedia bestanden en/of database dumps. In beide gevallen zijn er veel betere formaten beschikbaar dan XML.

Verder ben ik wel benieuwd naar de markt voor dit soort tools. Zeker in de Java wereld zijn er de nodige implementaties van XML tools die gewoon gratis beschikbaar zijn. Ik ben heel benieuwd hoe Intel een meerprijs van $ 5000 per licentie waar maakt. Aan het ontwikkelgemak zal het niet echt liggen want Jaxp is Jaxp. De performance moet dus wel een heel stuk beter zijn dan wat we nu kunnen krijgen.

Bovendien snap ik dat multithreaded verhaal op de site van Intel niet zo goed als het gaat om de Java implementatie. Hoe de JVM threads mapt op native threads/processen is niet iets dat een Java programmeur onder controle heeft. Fijn dat Intel wil laten zien dat je met multi-core meer bytes per seconde kan verwerken, maar dat wisten we natuurlijk al lang.

[Nappie]

Een XML file van meer dan 1 GB is niet absurd. XML wordt ook gebruikt in omgevingen voor hoog-volume printen. Dan kan je zomaar praten over 100.000 pagina's/documenten in XSL-FO, PPML of een ander formaat (bijvoorbeeld een eigen syntax met alleen de records uit een database).

[Bobco]

Dat is precies wat ik bedoel: XML is een standaardoplossing geworden die vaak zonder verder nadenken wordt gekozen. Vaak wordt XML ook gebruikt als verkoopargument: "Kunnen onze andere applicaties hiermee overweg? Ja, want ons output formaat is XML."

Als je naar dit soort grote bestanden gaat kijken is er natuurlijk de nodige overhead die geintroduceerd wordt door de XML tags die nodig zijn. Wat die verhouding tussen overhead en data is verschilt natuurlijk nogal, maar ik kom regelmatig bestanden tegen waarbij die verhouding iets van 30/70 is. Die 30% overhead komt overal in terug: tijd die nodig is om het bestand te lezen, te schrijven, te versturen en te parsen. niet super efficient. Een gemiddeld xsl:fo bestand zal wel iets beter scoren dan dat, maar ook daar zit die overhead in.

Zoals Janoz opmerkt: als het nodig is, is XML prima te zippen. Helemaal waar, maar dan gaat er weer een lading CPU cycles aan op, elke keer als je iets met dat bestand wil doen. Ik denk dat XML een beetje is als democratie: het is geen goed systeem, maar wel het beste dat we hebben als algemeen gestructureerd tekst formaat. De manier waarop je transformaties kan doen is krachtig en omdat er zoveel tools voor zijn is er gemakkelijk mee te werken.

[Crew One]

Je noemt het zelf al: *standaard* oplossing.

Even een XML-loos formaat als XSL-FO ontwikkelen en even doorvoeren in de rest van de wereld is toch niet echt realistisch. Soms zul je dus niet anders kunnen dan de uitvoer in een standaardformaat aan te leveren, ook al is het een suboptimale oplossing.

[Verwijderd]

Ik denk dat XML een beetje is als democratie: het is geen goed systeem,

Democratie is zoals XML, het idee is goed maar zorgt voor problemen als er teveel verschillende mensen/data zijn.

[hamsteg]

Oorspronkelijke doelstelling van XML is het interoperatable maken van systemen. Exporteren/Inpakken in XML vanuit de sourcesysteem, versturen en weer uitpakken/omzetten naar het targetsysteem. Een voorbeeld: voor webpagina's zie je dat het oorspronkelijke idee was dat je een deel van een database in XML omzet zodat deze op de HTML pagina meer interactief gebruikt kon gaan worden.

XML is nu geen middel meer geworden maar een doel en hier gaat het helemaal fout. XML is geen dBase maar een data drager !!! Van een data drager mag je niet verwachten dat je een dBase functionaliteit krijg met dezelfde requirements. Met XML wordt nu getracht alles op te lossen maar je zult nooit de efficiency halen van de dedicated applicaties/toepassingen.

Heb pasgeleden een configuratie-file gezien in XML ... hier is XML het doel geworden en moet ik door de structuren heen kijken om mijn settings te doen. Dit hoort zo niet, een parser hoort de settings in XML om te zetten en de XML code aan te bieden aan de doelapplicatie.

Gebruik van Hypes levert meestal dit soort groeistuipen op ... het zal vanzelf wel weer normaliseren en tot die tijd erger ik me er wel aan.

[Paridaen]

Ik denk dat Intel bedoelt dat hun XML-library zo geschreven is dat het goed gebruik maakt van meerdere threads, iets dat andere XML libraries niet vanzelfsprekend doen. Als je een XML file moet parsen en je kan dit met zeg 8 threads tegelijk doen zonder dat de threads elkaar in de weg zitten dan levert dit op een multi-cpu/multi-core systeem een aardige snelheidswinst op.

[Janoz]

Ruimte efficient maakt in principe niet zo heel veel uit. Aangezien een xml file veel tekst en gelijkvormige structuren bevat is het heel goed te comprimeren wanneer dat nodig is.

Daarnaast is het vaak ook niet om gegevens op te slaan, maar om gegevens door te sturen. Zeker in enteprise omgevingen kan de grootte hiervan behoorlijk oplopen. Op dit moment werk ik aan een verzekeringssysteem waarbij offertes en aanvragen via XML tussen front en backend verstuurd worden, en deze offertes zelf liggen al boven de 100k. Hiervoor heb ik in een medische omgeving gewerkt, en daar waren de afmetingen nog een stuk groter doordat hier natuurlijk ook binaire data bij zat (denk aan röntgen foto's)

Grote voordeel van XML is niet alleen dat het standaard is, maar dat er standaard tools zijn (xslt) om de ene opmaak te kunnen omzetten naar de andere opmaak. Het integreren van verschillende applicaties is daardoor een stuk makkelijker omdat er niet weer yet another binairy format omgezet moet worden in propriarity format Y. Een fatsoenlijk xslt script is voldoende.

[Reactie gewijzigd door Janoz op 26 juli 2024 15:03]

[Verwijderd]

Een van mijn vorige werkgevers deed file-type transformations (EDI, PDF, plain-text, XML, XSL, ...), de inhoud van die bestanden waren veelal orders, voorstellen, verschillende manieren van optimale stapelingen op paletten voor de transport afdeling en nog meer redelijk bizarre order-details (zoals als je er slechts zoveel hebt van A doe er dan maar gewoon 3* meer van B ).

Om dit allemaal vlot te doen verlopen werd alles eerst omgezet naar XML-bestanden, die dan via XSLT werden verder getransformeerd naar het bestand-type gebruikt door de ontvanger (en uiteraard was er ook een omgekeerde vertaling voor order bevestigingen, facturen enzo).

Zo een vertalingen zijn nu eenmaal nodig als iedereen verschillende systemen (en dus formaten) gebruikt. En daar heb ik XML bestanden gezien die tegen de 20GB aanliepen, dat waren de gegevens van de Belgische Spoorwegen voor de Sociale Zekerheid die elke maand werden verstuurd.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 15:03]

[Kristof]

Bijvoorbeeld een XML database:
http://en.wikipedia.org/wiki/XML_database

[YopY]

Het nadeel van XML databases tegenover 'conventionele' databases is dat óf ze zijn traag (bij zoekmethoden die het 'lineair' doorzoeken, van boven naar beneden), óf ze gebruiken ongeloofelijk veel geheugen (door het hele XML bestand in te lezen en in het geheugen doorzoekbaar te maken). XML databases klinken leuk en zijn misschien ook bruikbaar voor relatief kleine datasets of data dat alleen maar in één keer ingelezen hoeft te worden danwel niet-random ingelezen wordt, maar voor professionele toepassingen zou ik een XML database echt niet gebruiken.

Of deze toolkit moet een 1GB XML database kunnen doorzoeken in een acceptabele tijd zonder al te veel geheugengebruik.

[melgers]

Een beetje xml database heeft de mogelijkheid voor indexen niet als een gewone database. Relationele databases zijn ook traag (bij grote hoeveelheden data natuurlijk) als ze full table scans moeten doen.

Voor wat betreft het gebruik van XML databases voor professionele toepassingen neem ik maar aan dat je niet weet dat b.v. auto/motoren fabrikanten en vliegtuigbouwers vinden dat je dat wel kunt doen.

[Verwijderd]

er is een verschil tussen XML en SGML, waar het van afgeleid is.
ik denk dat veel fabrikanten ipv XML, hun eigen taal defniëren in SGML

[MneoreJ]

Dat acht ik niet erg waarschijnlijk. SGML is veel ingewikkelder, en SGML-talen worden voornamelijk gebruikt voor documenten in hun algemeenste vorm.

Je hebt nou net iets eenvoudigers als XML nodig om het allemaal nog een beetje efficiënt te kunnen verwerken. Een databasesysteem dat SGML zou verwerken is ondoenlijk, en een custom-taal op basis van SGML loont zich niet omdat je dan weer niet interoperabel bent met de rest van de wereld die XML gebruikt.

Er zijn genoeg systemen die met een SGML-taal werken, maar dat zijn meestal geen databases. Als die documenten geïndexeerd en doorzocht moeten worden zal er een gewone RDBMS achter zitten.

[ATS]

Ik ben het met je eens dat je geen XML database gaat inzetten voor iets dat je eenvoudig kan representeren in een relationele database, zeker niet als het veel data betreft. Maar niet alles laat zich eenvoudig uitdrukken in zo'n structuur, en dan kan het handig of logisch zijn om XML te gebruiken, zeker als je daarmee bestaande, gestandaardiseerde definities van onderdelen van je data kan embedden in je structuur.

[Arch-IT-ect]

Bwoah, voor websites te maken en kleine databases is XML imo wel heel handig en sneller dan een database. check http://www.swinggroup.eu, website volledig uit XML, laadt zeer snel, makkelijk aan te passen en we zijn bezig met modules aan te koppelen die ook allemaal uit XML komen, dit gaat een stuk sneller dan voorheen, toen we het uit de database haalden. Natuurlijk, voor sites met een massa aan gegevens en ingewikkelde queries is een database nog altijd meer voor de hand liggend, tenzij je gegevens kunt opsplitsen in meerdere xmlfiles. Dus ik denk dat ik je hierin gelijk moet geven, dat xml-files van 1GB echt no go zijn (in mijn ogen althans)

[Reactie gewijzigd door Arch-IT-ect op 26 juli 2024 15:03]

[? ?]

waarom zou je in godsnaam zoiets in XML gaan zetten als je mysql hebt dat daarvoor gemaakt is? als mysql trager was bij jou, doe je iets verkeerd of gaat 't over bestandjes van een paar kB
XML is om data van de ene applicatie/site/plaats/... naar de andere over te zetten zodat de sender en receiver het formaat zonder probleem kunnen lezen. Voor al de rest dient XML niet imho.

[Reactie gewijzigd door ? ? op 26 juli 2024 15:03]

[Arch-IT-ect]

Voor elk onderdeel zijn het apparte xml files, menu, rss, tekst, themabalk, breadcrumbs, ... moesten we het in een db steken, dan was het MSQL, en toen ik hiermee testte, bleek dat xml een pak sneller ging.

[Verwijderd]

EDan had je meer nadruk moeten leggen op caching. Als je elke keer een database gaat raadplegen voor een menu dat maar heel af en toe verandert, is dat inderdaad relatief traag.

Mijn ervaring is echter dat productiemachines vaak zo snel zijn dat dát niet eens merkbaar is, zolang je niet met recursie aan de gang gaat.

Overigens is het zwaarste onderdeel van ons (zelf ontwikkelde) framework het inlezen van XML bestanden. Die bevatten de configuratie van de database en dergelijke. En juist, de geparsete XML wordt omgezet naar een objectstructuur die we cachen.

[YopY]

Voor redelijk statische content (menu's, instellingen e.d.) is XML misschien handiger dan een database, maar voor dingen als dynamische content (nieuws, reacties, posts etc) kan ik voorstellen dat een DB daarvoor geschikter is.

[Klaus_1250]

MySQL is een database, e.g. bedoelt voor zaken waarbij zowel lezen en schrijven/updaten, etc belangrijk is en die goed doorzoekbaar moet zijn.
MySQL gebruiken om praktisch statische data via php in html te mikken is complete overkill (in feite gebruik je dan beide als een template systeem). Het vervolgens geforceerd toch een beetje sneller maken door een phpAccelerator en caching servers te gebruiken is dan gewoon geld weggooien.

XML is absoluut NIET puur en alleen om data over te zenden tussen een zender en ontvanger (meer 1 van de grote voordelen). Ander groot voordeel van XML is dat je in combinatie met XSLT, XPath je er zo'n beetje alles gestructureerd mee kan doen, waaronder een website maken in XML voor de inhoud en XSLT en XPath als template systeem. (En via SVG kan je XML-data omzetten in dynamische vector-graphics).

Een beetje geavanceerde browser kan dit zelfs client-sided doen, waardoor je websites een stuk sneller en bandbreedte-vriendelijk kan maken.

[KMK]

Ik doe het doorelkaar heen.. XML data in een database field.
MS-SQL 2005 heeft hier een speciaal datatype voor.
MySQL is het aan het onwikkelen.

Er is ook een extra SQL query aka SQL/XML
http://www.stylusstudio.com/sqlxml_tutorial.html

[Reactie gewijzigd door KMK op 26 juli 2024 15:03]

[BCC]

Helaas hebben veel grote software pakketten als enige handige optie een XML input / output om dingen te koppelen. En ja, dat is ineffecient, maar als je het zipped is het allemaal nog best behapbaar. Het parsen is dan de bottle neck en dit is weer een stap in de goede richting. Ik wil echter wel graag zien hoeveel dit bijvoorbeeld sneller is dan libXML.

[Sgreehder]

Digitaal forensisch onderzoek bijvoorbeeld.

[Thundy]

Sorry maar mijn inziens is ieder XML bestand groter dan 10 megabyte en design-flaw in de software die het produceerd.

[Verwijderd]

Ik zie niet in waarom een XML bestand niet groter zou mogen zijn dan 10 megabyte, er is toch ook niemand die klaagt als ik een bitmap image maak van 10 megabyte ?

Het enige probleem dat ik zie is dat grotere bestanden zwaarder zijn om te verwerken. Maar als je die XML van 10 megabyte in een flatfile gaat steken (zoals EDI bijvoorbeeld) dan heb je veel complexere logica nodig om het te verwerken, zelfde effect als je het gaat verspreiden over diverse bestanden. En als je al die data in een database hebt steken heb je nog een database draaiend te houden, plus in veel gevallen is de hele inhoud van zo'n XML op elk moment relevant, ga je een query uitvoeren op je database om alles in je geheugen proppen ? Of meerdere queries achter elkaar uitvoeren ?

[YopY]

Niet beslist, dat is afhankelijk van de opgeslagen data. Ikzelf werk met rapportagesystemen die de broncode van een programma analyseren en aan de hand daarvan een XML-rapport schrijven. Het programma waar ik aan werk moet deze XML bestanden vervolgens inlezen en bereikbaar maken in een webapplicatie. De opmaak / structuur van deze XML bestanden is altijd gelijk; de groote ervan is echter afhankelijk van de groote van het project waar de rapportagetool op losgelaten wordt. En projecten van duzenden klasses zijn geen uitzondering, wat XML rapporten van tientallen, zo niet honderden MB's op kan leveren.

Zolang het oorspronkelijke doel van een XML bestand (gebruik tussen applicaties) niet uit het oog verloren wordt, is de uiteindelijke groote van een XML bestand niet belangrijk - laat staan een design flaw.

[Buzz_Fuzz]

Wij hebben hier een tool draaien die gegevens uit een object-oriented DB dumped naar een XML file zodat een andere tool die gemakkelijk kan inlezen. Zo 1 dump kan een paar 100 MB groot zijn, en vaak zijn er 20 dumps per run.... Sorry, maar als je nu eenmaal zoveel informatie hebt, zie ik niet in waarom je met bestandjes van 10MB moet gaan prutsen ...

[borft]

precies, bovendien biedt xml een groot voordeel boven de traditionele relationele databases: het is niet relationeel, maar hierarchisch! Hier door zijn er hele uitgebreide query mogelijkheden, zie ook xquery en xpath.

Dat er nog geen implementaties zijn, die supersnel zijn, betekent niet dat de technologie waardeloos is, maar meer dat het nog zwaar onder ontwikkeling is.

[YopY]

nein, het probleem van het gebrek aan supersnelle implementaties ligt hem helemaal in het ontwerp en de structuur van XML. Er zijn ruwweg twee mogelijkheden om een XML bestand in te lezen: streamend (boven naar beneden e.d.), wat relatief weinig geheugen inneemt, of alles in een, wat relatief snel is maar waarbij het nodig is om het hele XML bestand te parsen en in het geheugen te laden. Zeg maar SAX en DOM, beide hebben hun voor of nadelen. Snelheidswinsten zijn misschien nog te behalen door bijvoorbeeld het sorteren van de records in een XML bestand (zodat je geavanceerdere zoektechnieken kunt gebruiken) of door een XML bestand multithreaded door te zoeken, maar verder zie ikzelf weinig toekomst in XML databases wanneer het aankomt op snelheid of efficientie.

[albatross]

Het is dat ik zelf al gereageerd heb in deze thread, want anders had ik je comment als trollerig weggemodereerd.

Kijk, toen ik een jaartje terug met SPF bezig was, weet ik nog dat MS zeer hevig aandrong om SPF records onder te gaan brengen in XML. Daar hebben we ons toen hevig tegen verzet, en het is uiteindelijk gelukkig ook niet doorgegaan. Geen bloatware in DNS, please. Maar voor iedere andere vorm van uitwisseling is XML goed geschikt.

En tja, soms is je data zelf al groter dan 10MB. Je klinkt toch een beetje als Bill Gates die destijds zei dat niemand ooit meer dan 640K geheugen nodig zou hebben.

[ARNI]

Hier zat ik op te wachten. Grote xml bestanden inlezen duurt te lang met de software van tegenwoordig waardoor je haast niet meer kunt werken op je workstation.

Ik ben beniewd hoe dit programma hiermee omgaat.

[Bastiaan V]

streaming is een prima oplossing voor grote bestanden, enige wat dan (veel) geheugen zal eten zijn (extreem) diepe nestings.

[Dreamvoid]

Voor een hoop mensen lijkt XML parsing ver-van-mijn-bed, maar een klassiek voorbeeld van de bottlenecks is iTunes, dat bij het opstarten zijn XML library inleest en parsed naar een tijdelijke binaire DB (dat zoekt sneller), en bij het afsluiten weer het omgekeerde doet. Dat duurt bij een grote library van een paar 10.000 items met bakken aan metadata al gauw een eeuwigheid.

[Jrz]

XML gebruik je niet als opslag, maar als uitwisseling

[Nick_S]

Stel je een drietal systemen voor:
- Een CMS (Aanmaken en wijzigen van documenten)
- Een repository (Opslag van documenten)
- Een frontend (tonen van documenten)

CMS wisselt data uit met de repository.
Frontend wisselt data uit met repository.

Waarom zou je dan je uitwisselformaat anders maken als je opslagformaat?

Voor doorzoekbaarheid hoef je het niet te doen, daarvoor gebruik je indexers op het moment dat een document wordt opgeslagen.

Zie Java Content Repository standaard, Jackrabbit, Hippo. Opslag in XML is best te doen.

[Wouter Tinus]

Deze toolkit is natuurlijk ook uitgebracht met het oog op de Nehalem-processorgeneratie, die hardwarematige instructies krijgt om het werken met strings (dus ook het parsen van tekstfiles zoals xml) te versnellen. Deze toolkit zal dan nog wel een stuk sneller worden.

[albatross]

Nou droom je toch een beetje. Daar zul je nauwelijks iets van merken. De I/O is hier natuurlijk altijd ruimschoots de bottleneck. Bovendien zal je compiler specifiek van deze instructies gebruik moeten gaan maken; en dan ook zal het gebruik van die instructies precies moeten overlappen met de hogere xml parsing calls.

[Wouter Tinus]

Nou droom je toch een beetje. Daar zul je nauwelijks iets van merken. De I/O is hier natuurlijk altijd ruimschoots de bottleneck.

Oh, dus ze hebben deze hele library voor niets uitgebracht. Sorry Intel, leuk geprobeerd, maar de I/O is "natuurlijk altijd ruimschoots" de bottleneck, dus dump maar weer deze software. En iedereen die werkt aan hardwarematige xml-versnellers kan ook meteen inpakken.

. Bovendien zal je compiler specifiek van deze instructies gebruik moeten gaan maken;

Ja, en dat is dus het voordeel van zo'n bibliotheek. Alleen Intel hoeft de ondersteuning in te bakken en iedereen die de software gebruikt profiteert ervan.

[Reactie gewijzigd door Wouter Tinus op 26 juli 2024 15:03]

[albatross]

Oh, dus ze hebben deze hele library voor niets uitgebracht. Sorry Intel, leuk geprobeerd, maar de I/O is "natuurlijk altijd ruimschoots" de bottleneck, dus dump maar weer deze software. En iedereen die werkt aan hardwarematige xml-versnellers kan ook meteen inpakken.

Nee, het ging erom dat je zei: "Deze toolkit is natuurlijk ook uitgebracht met het oog op de Nehalem-processorgeneratie." En dat is natuurlijk niet zo. Ten eerste zitten die extra Nehalem instructies er nog niet in (en als ze er al in zouden zitten zou het, zoals ik al zei, weinig uitmaken, want je moet eindeloos veel langer wachten op de I/O dan op de CPU verwerking van de parsing). En ten tweede komen die Nehalem instructies er ook niet in, want dan zouden die libraries op alle huidige generaties duo- en quadcores niet meer werken, Exit Nehalem argument.

[Paridaen]

Een I/O bottleneck is altijd op te lossen. Gewoon meer disken of storage arrays eronder.

[Verwijderd]

En toch ook het verkeer tussen integratie en applicatielaag? Dus data van app's naar de enterprise service bus.

[_Thanatos_]

Pfft. XSLT 1.0 is oud. Jammer hoor. Als ze nou es iets moderns zouden uitbrengen...

[MneoreJ]

Dan schrijf je toch lekker zelf een supersnelle library voor XSLT 2.0?

Het gaat toch zeker om wat gebruikt wordt? Het doel van deze library is bestaande dingen sneller doen. De mensen die XSLT 2.0 ondersteuning nodig gaan hebben kun je tellen.

[_Thanatos_]

Dan ben je lang bezig (met tellen). XSLT 2.0 gebruik je per definitie al als je met .NET 2.0 of hoger bouwt. Je moet juist voor XSLT 1.0 een hele goeie reden hebben, want het biedt alleen maar nadelen t.o.v. 2.0.

[g4wx3]

XML zou eigenlijk alleen gebruikt mogen worden bij "tijdelijke databses", bijvoorbeeld om data gextraheerd uit een echte database tijdelijk op te sleen, om deze achteraf te kunnen gebruiken, om op een makkelijke manier toegankelijk te maken (DOM objects)

Ik gebruik het niet, maar het is dus een soort tussenstadium tussen de echte database, en de output