[xml] wie houdt er van.. wie haat het.

[Alarmnummer]

Iedere keer als ik met XML aan de slag moet zit ik weer van... ok.. dat wordt in ieder geval voor java weer graaien in de wereld tools/tutorials/documentatie (die slecht onderhouden is).

Ik ben in ieder geval zeker niet blij als ik met XML en XML gerelateerde technieken aan de slag moet. Schema`s kan ik redelijk standaard opzetten omdat ik dus 1 techniek heb die ik consequent doorvoer en met normale XML heb ik ook geen problemen. Maar als ik bij bv XSLT of XML-gebaseerde middleware aan kom zit ik 10.000 keer van hmmm.. waarom werkt dit nu niet.

Je kunt uiteraard zeggen.. dan moet je er meer tijd in steken.. dan leer je het begrijpen. Dat zal allemaal best.. en als ik veel tijd over had zal ik dat ook zeker doen. Helaas heb ik die tijd niet over en zit ik met de keren dat ik ermee moet werken weer met *slik*.

Daarnaast komt nog een keer alle problematiek van Java en XML. Voor java heb je de grote jongens zoals Xalan en Xerces. Dat vind ik een goeie ontwikkeling. En verder heb je nog een keer JDom als je een DOM wilt. Maar dan komt Sun ook aanzetten met allemaal implementaties waar ik eerlijk gezegd de ballen van begrijp en ik ook totaal niet kan plaatsen binnen de bestaande tools.

En uiteraard heb je ook nog SOAP. SOAP is ook al zo`n drama op Java. Je hebt AXIS, maar als ik eerlijk bent werkt dat gewoon bagger. Foutmeldingen zijn naad, documentatie is rond uit kut. En uiteraard probeerd Sun ook een implementatie te maken, maar die was tot voor kort geleden gebonden aan een speciale versie van Tomcat -> heb ik dus ook niets aan,

Mijn stelling:
Voor XML zijn dus de wereld specs... maar voor de developer die zo nu en dan XML moet gebruiken is het ronduit een drama.

[ Voor 4% gewijzigd door Alarmnummer op 19-01-2005 18:11 ]

[RobIII]

Ik heb an sich geen probleem met XML. Ik gebruik het veel i.c.m. het MSXMLDom object in ASP (VBScript) / VB / Javascript en ik heb de nodige XSLT's gemaakt. Ik heb er niet zo'n moeite mee eerlijk gezegd en vind het wel fijn werken.

SOAP heb ik nog niks mee gedaan (ik maak meestal mijn eigen "implentaties" ) maar ik vind het ook erg afhankelijk van hoe je XML er uit ziet. Ik kom soms XML documenten met DTD's e.d. tegen waarbij ik ook zoiets heb van WTF Mijn XML documentjes zijn meestal redelijk "kaal" en niet erg uitgebreid. Misschien dat dat ook scheelt...

[drm]

Ik denk dat je 't in dit geval meer hebt over de implementatieproblemen van allerlei vormen van XML in Java. Ik weet dat de standaardimplementaties in .NET bijvoorbeeld al veel beter zijn. Dus ik begrijp je frustratie wel (ben er ook wel eens tegenaan gelopen, vooral XSLT is echt een drama) maar 't ligt imo niet aan XML, maar aan Java (of aan de overvloed van implementaties en het gebrek aan goede implementaties)

[Alarmnummer]

drm schreef op woensdag 19 januari 2005 @ 18:17:
Ik denk dat je 't in dit geval meer hebt over de implementatieproblemen van allerlei vormen van XML in Java. Ik weet dat de standaardimplementaties in .NET bijvoorbeeld al veel beter zijn.

Yep.. dat vond ik ook een zeer positief punt aan .NET. Geen gezeik.. geen keuzes.. het zit er gewoon in. Geen gefuck met allerlei tools waarbij je je af vraagt.. in hoeverre zit er overlappende functionaliteit in... en ben ik dat nodig? Java gooit zoals gewoonlijk zijn eigen ramen in.

[edit]
Ik ben bv al een half uur aan het zoeken hoe ik in godsnaam een XQuery kan uitvoeren en hoe ik een XML document kan parsen. Parsen kan met Xerces.. maar kan je ook XQuery uitvoeren? Parsen kan met JDOM maar tis me niet duidelijk of je XQuery kan uitvoeren. En zo loop je van de ene tool naar de andere tool. Alsof ik niets beters met mijn tijd te doen heb.

Dus ik begrijp je frustratie wel (ben er ook wel eens tegenaan gelopen, vooral XSLT is echt een drama) maar 't ligt imo niet aan XML, maar aan Java (of aan de overvloed van implementaties en het gebrek aan goede implementaties)

Hmmm.. dat ben ik niet met je eens. Op het moment dat je wat dieper de XSLT in duikte dan snap je er ook sowieso de ballen meer van. Verder zijn de meeste XML gebaseerde 'talen' ook fout. Mensen zijn doorgeslagen.. je krijgt zo snel van die onwerkbare troep.

[ Voor 18% gewijzigd door Alarmnummer op 19-01-2005 18:28 ]

[megamuch]

* megamuch herkent zich volledig in het verhaal van Alarmnummer.

XML is een mooie techniek, maar om 1 of andere reden wil de techniek om het te implementeren mij nog niet echt lekker bezig houden. Ik blijf zoeken in de documentatie en de gebruikte "standaard" functies. Af en toe zie ik XML doc's en dan heb ik geen idee waar het over gaat. Wat toch 1 van de voordelen zou moeten zijn van XML.

Dat laatste is natuurlijk per document verschillend, maar het is eerder regelmaat dan uitzondering in mijn persoonlijke ervaring.

[Verwijderd]

.NET heeft inderdaad zijn XML zaakjes redelijk op orde.

Waar ik me persoonlijk ook aan erger is dat klanten altijd beginnen over XML (zit zelf in de document management hoek). Het is echt weer zo'n hype. Je weet (bij ons iig) altijd dat een klant over twee dingen gaat beginnen; als het gaat om uitwisseling: XML, als het gaat om versturen: PDF.

Voor mijn gevoel is bij veel applicaties de zogenaamde "XML support" er zo snel mogelijk tussengemoffeld om maar niet achter te lopen. Echt volwassen is deze zogenaamde ondersteuning vaak nog niet (in de applicaties waar ik mee te maken krijg that is).

[ Voor 28% gewijzigd door Verwijderd op 19-01-2005 19:38 ]

[MisterData]

Ik werk de laatste maanden ontzettend veel met XSLT/XML in PHP en XSLT/XML in Java, en beiden gaan me erg goed af Ik vind het werken met XSLT zelfs leuk, omdat het, als je het een beetje door hebt, ontzettend krachtig is. Zo heb ik laatst in XSLT iets gemaakt waarmee je met een XML-bestand met een zooi getallen en een settings-bestand dat er uitziet zoals hieronder hele kolommen automatisch kunt berekenen; oneindig diep

XML:

<CustomColumn name="Sommetje">
<Sum>
<Col ref="SA_19"/>
<Col ref="SA_23"/>
<Multiply>
<Col ref="SA_1"/>
<Col ref="SA_2"/>
</Multiply>
</Sum>
</CustomColumn>

Dat zijn dingen waarbij je XSLT echt tot het randje gebruikt. Ik ben in tegenstelling tot Alarmnummer erg tevreden met de Java-implementatie van XML en XSLT: DOM werkt goed, XSLT support bijna alles en is in vergelijking met PHP retesnel (overigens gebruik ik geen JDOM of wat dan ook, gewoon de 'ingebouwde' DOM, werkt perfect, en JAXP). Enige waar ik vaak tegenaan loop is dat foutmeldingen altijd netjes worden gegeven, maar dat ik bij XML-syntax fouten niet altijd het goede regelnummer e.d. te zien krijg, maar dan wel weer 10 regels stacktrace waar ik niks mee kan

[whoami]

Ik heb idd het voordeel dat ik niet teveel 'externe' tools nodig heb om met Xml te werken in .NET.

Momenteel werk ik aan een project waar er nogal intensief gebruik gemaakt wordt van xml om data-uitwisseling te doen tussen applicaties; en binnen datzelfde project wordt xml ook gebruikt om bepaalde config. files te maken.

Behalve XmlSpy heb ik eigenlijk geen externe tools nodig (of nog niet nodig gehad).

[prototype]

Ik vind XML uitermate fijn vanwege portability in data. In combinatie met XSL is het een uitermate krachtige tool. Wat me opvalt is dat men laatst genoemde veelal combineert met XML om XHTML te genereren. Maar dan doe je XSL echt te kort, pdf's genereren, compilable code genereren etc... is ook allemaal mogelijk. Tsjah wat betreft implementaties, 'k heb de nare gewoonte om m'n eigen 'tools' te gebruiken/ontwikkelen in plaats van bestaande (bewezen) tools te gebruiken. Heel stom misschien, maar 't gaat mij meer om de leerervaring van het opbouwen van iets dergelijke, wel probeer ik zoveel mogelijk bij de API van bestaande modules te blijven dus mocht ik 't halverwege opgeven dan kan ik 't geheel vrij eenvoudig omzetten.

[ Voor 4% gewijzigd door prototype op 19-01-2005 21:19 . Reden: En anders is een adapter ook snel geschreven :P ]

[Bobco]

Zelf gebruik ik XML veel als formaat voor (grote) configuratiefiles. Schema maken, JAXB eroverheen en je hebt al heel snel een stuk code dat automatisch controleert of alle verplichte elementen wel aanwezig zijn. Kost bijna geen moeite en het werkt ook de andere kant op.

De combinatie van XML en Java is rijk, maar op sommige punten ook rijk aan problemen. Probeer bijvoorbeld maar eens een applicatie op OC4J te deployen waarbij je gebruik wilt maken van een andere XML parser dan degene die Oracle meelevert.

SOAP is een ander verhaal. Ik zie de voordelen nog niet zo voor data-uitwisseling tussen applicaties binnen een bedrijf. XML over HTTP doet het ook prima zonder envelopjes.

[Alarmnummer]

prototype schreef op woensdag 19 januari 2005 @ 21:17:
Ik vind XML uitermate fijn vanwege portability in data. In combinatie met XSL is het een uitermate krachtige tool. Wat me opvalt is dat men laatst genoemde veelal combineert met XML om XHTML te genereren. Maar dan doe je XSL echt te kort, pdf's genereren, compilable code genereren etc... is ook allemaal mogelijk. Tsjah wat betreft implementaties, 'k heb de nare gewoonte om m'n eigen 'tools' te gebruiken/ontwikkelen in plaats van bestaande (bewezen) tools te gebruiken. Heel stom misschien, maar 't gaat mij meer om de leerervaring van het opbouwen van iets dergelijke, wel probeer ik zoveel mogelijk bij de API van bestaande modules te blijven dus mocht ik 't halverwege opgeven dan kan ik 't geheel vrij eenvoudig omzetten.

Dat kan je doen als je iets voor jezelf maakt. Maar als je iets voor je werk meot doen is het anders. Dat je 1 stap van het oplossings pad af moet om de oplossing voor elkaar te krijgen vind ik geen probleem. maar als ik 2/3 of meer stappen weg moet dan weet ik dat ik met een complex oplossingspad te maken heb waarin veel onzeker/onduidelijkheden zitten. En met java/xml weet ik dat het me zo een aantal uren extra gaat kosten.

Ik ben dus niet geinteresseerd in XML. Ik wil een oplossing voor een probleem. Soms is XML daarvoor noodzakelijk en daar heb ik begrip voor. Maar ik wil niet godsellendig veel uitzoek werk doen omdat de tutorials kut zijn, en de tools bij elkaar geraapt. Ik vind XML niet zo`n probleem.. en ik heb ook al wat leuke dingetjes met XSLT gedaan.. maar het is altijd zo`n godsellendig probleem om aan de goeie informatie te komen.

[Onno]

Het is wel een terugkerend thema he? Je gebruikt iets niet zo vaak en vergeet daardoor elke keer weer hoe het werkt, dus moet er een zeurthread aan gewijd worden..

Ik gebruik XML trouwens vrij veel, ook in Java, en kan niet echt zeggen dat ik het met je eens ben. Voor het genereren van output in het algemeen, en PDF/RTF/enz documenten in het bijzonder (XSL-FO) is het praktisch, XML-RPC/SOAP werkt lekker bij distributed code (zeker als je compleet verschillende talen door elkaar heen gebruikt), ant is geweldig als build-tool, enz. enz.

(overigens, de XML/XSL implementaties die Sun met je JVM meelevert zijn gewoon Xerces/Xalan, dus dat punt snap ik ook al niet)

[Alarmnummer]

Onno schreef op donderdag 20 januari 2005 @ 00:27:
Het is wel een terugkerend thema he? Je gebruikt iets niet zo vaak en vergeet daardoor elke keer weer hoe het werkt, dus moet er een zeurthread aan gewijd worden..

Veel technieken gebruik je niet vaak, maar als je ze moet gebruiken wil je er niet een enorme lading tijd in steken om de basis zaken voor elkaar te krijgen. Ik werk in tegenstelling tot sommigen wel in een omgeving waarin je niet te lang op iets triviaals kunt hangen en waar er geld verdient moet worden.

Als jij dit beschouwt als een stuk gezeur dan is dat jouw probleem.

Voor het genereren van output in het algemeen, en PDF/RTF/enz documenten in het bijzonder (XSL-FO) is het praktisch,

Het kan handig zijn, maar XSLT is wel typisch weer zo`n taal die een XML syntax heeft en eigelijk is dat ook al iets totaal fouts. XML moet niet gebruikt worden om in te programmeren, alleen data uit te wisselen. Als je wilt kan ik je wel even een leuk artikeltje geven waarin Terence Parr wat leuke kritiek uit.

XML-RPC/SOAP werkt lekker bij distributed code (zeker als je compleet verschillende talen door elkaar heen gebruikt),

Ik weet niet of je het ook met Java hebt geprobeerd, maar het is daar alles behalve duidelijk.

ant is geweldig als build-tool, enz. enz.

Uiteraard. Ik heb ook geen problemen met XML als basis. Het scheelt weer een parser schrijven en je kunt eenvoudig data uitwisselen. Maar het gaat mij om alle technieken om XML heen. Voordat je ergens bent, ben je al 20 acroniemen tegengekomen.

(overigens, de XML/XSL implementaties die Sun met je JVM meelevert zijn gewoon Xerces/Xalan, dus dat punt snap ik ook al niet)

Ik heb idd gezien dat er ergens Xerces/Xalan onderdelen in de JVM rondzweven. Maar als die zo goed zijn, waarom worden ze dan altijd nog een keer meegeleverd met distributies van allerlei tools (zelfs die voor 1.4 zijn gemaakt). Het is me verder ook totaal niet duidelijk hoe Sun hun JAX gebeuren in dit verhaal past.

[ Voor 5% gewijzigd door Alarmnummer op 20-01-2005 00:50 ]

[Verwijderd]

Ik zie de voordelen van XML. Ben ook van plan binnenkort echt met XML te beginnen. het schijnt makkelijk te leren enzo. ben benieuwd .

als er goede tutorial en of boeken zijn hoor ik het graag

[Soultaker]

Java weet ik niet precies, maar ik heb wel goede ervaringen onder C en Python, met zowel content generators en SAX parsers. Ik gebruik onder C gewoon libxml2 en Python de standaard dingen. Zolang je niet al te ingewikkelde dingen hoeft te doen is SAX ideaal om grote hoeveelheden data snel te verwerken.

Met DOM heb ik nog niet zoveel gedaan; ik kan me voorstellen dat dat handig is voor complexere maar kleine bestanden zoals configuratiebestanden. Ik configuratiebestanden tegenwoordig zeker in XML inlezen en wegschrijven (behalve onder Windows misschien); het is veel makkelijker om wat simpele code te schrijven om XML in te lezen en weg te schrijven dan je eigen bestandsformaat te verzinnen en daar correcte generatoren en parsers voor te maken die correct omgaan met unicode en escape characters e.d.

Verder zijn XML-documenten wat 'vrijer' in lay-out; het geeft meestal niet als je ergens een element of een attribuut mist en in zowel SAX als DOM valt daar makkelijk rekening mee te houden. Dat is handig, bijvoorbeeld weer bij een configuratiebestand: als je dan een applicatie update waardoor er meer opties gekomen zijn, is niet je configuratiebestand direct ongeldig (wat wel een probleem is met een binary formaat). De Windows registry heeft trouwens hetzelfde voordeel.

Het probleem met validatie is dat het heel erg makkelijk kan zijn (libxml2 kan bijvoorbeeld gewoon tijdens het parsen validatie tegen een DTD doen en dan hoef je er zelf bijna niets meer mee te doen), maar dat je inderdaad wel afhankelijk bent van de mogelijkheden die de library die je gebruikt je biedt. Als je bijvoorbeeld een ander soort schema gebruikt dan heb je een probleem; dan moet je alle validatie zelf doen, of je moet de parser en de validatie-library aan elkaar zien te knopen (wat via SAX zou moeten kunnen).

[MSalters]

Waarom zou je XML niet gebruiken om transformaties in op te slaan? Je moet niet proberen om het zelf met notepad/vi (pick your poison) te schrijven, maar dat geldt voor alle soorten XML documenten. XSLT is vanuit die invalshoek redelijk. Mijn probleem met XSLT is dat ik nog niet begrijp hoe dat een performance beter dan glaciaal gaat opleveren. XML in het algemeen is geen snelheidswonder.

[drm]

Alarmnummer:
Het kan handig zijn, maar XSLT is wel typisch weer zo`n taal die een XML syntax heeft en eigelijk is dat ook al iets totaal fouts. XML moet niet gebruikt worden om in te programmeren,

Je moet 't ook niet zien als programmeren maar transformeren. Steek data van het ene jasje in het andere, veel meer moet je er ook niet mee willen kunnen, imo.

alleen data uit te wisselen.

Data die dus wel eens getransformeerd moet worden, tada XSLT

Als je wilt kan ik je wel even een leuk artikeltje geven waarin Terence Parr wat leuke kritiek uit.

Ik ben wel benieuwd naar dat artikeltje Ik vind XSLT als concept erg sterk juist.

[Alarmnummer]

MSalters schreef op donderdag 20 januari 2005 @ 09:56:
Waarom zou je XML niet gebruiken om transformaties in op te slaan? Je moet niet proberen om het zelf met notepad/vi (pick your poison) te schrijven, maar dat geldt voor alle soorten XML documenten.

Meestal edit ik standaard XML gewoon in mijn editor (crimson editor) en met standaard XML heb ik geen problemen. Netjes uitlijnen en goed commentaar erbij en ik ben een gelukkig man. Verder heeft IDEA ook perfecte XML ondersteuning met oa code completion en syntax checking. Werkt erg prettig.

XSLT is vanuit die invalshoek redelijk

Hmm tja.. ik vind dat het idee achter transformaties helemaal ondersneeuwt onder een onduidelijke syntax. Ik kan het niet even lekker weglezen zoals ik met bv java ben gewent en dat terwijl de constructies vaak helemaal niet zo gecompliceerd zijn. Ik doe bv ook veel xml generatie met Lucene (een template engine voor Java) en dat vind ik een stuk prettig werken.

. Mijn probleem met XSLT is dat ik nog niet begrijp hoe dat een performance beter dan glaciaal gaat opleveren. XML in het algemeen is geen snelheidswonder.

Ik heb daar nog geen problemen mee gehad.

[TheJee93]

Ik werk nu al zo'n 1,5 jaar met XML. Samen met XSLT en Apache Cocoon kan je er erg veel krachtige dingen mee doen. Veel dingen zoals XML -> pdf met behulp van xslfo zitten standaard in cocoon, waardoor je veel mogelijkheden hebt, waar de klant vaak naar vraagt.

Ik vraag mij eigenlijk af of er hier meer mensen zijn die met Cocoon werken?

[ Voor 16% gewijzigd door TheJee93 op 20-01-2005 10:32 ]

[Alarmnummer]

drm schreef op donderdag 20 januari 2005 @ 10:19:
[...]
Ik ben wel benieuwd naar dat artikeltje Ik vind XSLT als concept erg sterk juist.

Ik heb geen problemen met het idee achter XSLT, maar wel met de syntax.

Humans should not have to grok XML

[Soultaker]

TheJee schreef op donderdag 20 januari 2005 @ 10:30:
Ik vraag mij eigenlijk af of er hier meer mensen zijn die met Cocoon werken?

Ik heb eens op een Pentium III 550 MHz met voldoende geheugen een server getest op basis van Tomcat en Cocoon. Ik had een simpel document (paar paragrafen) in DocBook format dat ik met de standaard XSL files voor DocBook omzette in HTML. Dit duurde meer dan een halve minuut! Dat is natuurlijk compleet onacceptabel.

Toen heb ik het maar weer gedeïnstalleerd, want als je geen realtime transformaties kan doen heeft het hele Cocoon gebeuren niet zoveel zin. Dan kan ik wel m'n documenten eerst transformeren en dan statisch serveren.

[ Voor 16% gewijzigd door Soultaker op 20-01-2005 10:40 ]

[whitehouse]

gebruiken jullie het nou voor het produceren van lijsten e.d. of wordt het zo ver doorgevoerd dat zels een login scherm in xml / xslt wordt omgetoverd ?

[TheJee93]

Soultaker schreef op donderdag 20 januari 2005 @ 10:40:
[...]

Toen heb ik het maar weer gedeïnstalleerd, want als je geen realtime transformaties kan doen heeft het hele Cocoon gebeuren niet zoveel zin. Dan kan ik wel m'n documenten eerst transformeren en dan statisch serveren.

Ik weet niet wanneer je dit geprobeerd hebt, maar ik denk dat er sinds dien genoeg is verandert. Op mijn werk gebruiken wij voor alle projecten Cocoon, waarbij alle sites live getransformeerd worden. Zelf intranetten bij grote klanten gaan als een trein met 5000 users. Daar maken we dan ook wel gebruik caching in de Apache server, maar de load trekt cocoon prima net als de live transformaties.

[whitehouse]

waarom gebruik je voor documentatie XML en geen PDF ?

[TheJee93]

whitehouse schreef op donderdag 20 januari 2005 @ 10:48:
waarom gebruik je voor documentatie XML en geen PDF ?

Met XML kan je de data mooi omschrijven. Vanuit XML kan je eventueel je data ontsluiten naar meerdere media, zoals XML, XHTML, HTML, PDF, WAP you name it.

[curry684]

TheJee schreef op donderdag 20 januari 2005 @ 10:30:
Ik werk nu al zo'n 1,5 jaar met XML. Samen met XSLT en Apache Cocoon kan je er erg veel krachtige dingen mee doen. Veel dingen zoals XML -> pdf met behulp van xslfo zitten standaard in cocoon, waardoor je veel mogelijkheden hebt, waar de klant vaak naar vraagt.

Ik vraag mij eigenlijk af of er hier meer mensen zijn die met Cocoon werken?

Cocoon gaan we hier bij Philips binnenkort ook gebruiken ja, voornamelijk om PDF's te genereren

Verder gebruik ik XML intensief, maar vrijwel alleen als dataopslag-methode, niet om pagina's mee te genereren of te transformeren.

[Genoil]

TheJee schreef op donderdag 20 januari 2005 @ 10:30:
Ik werk nu al zo'n 1,5 jaar met XML. Samen met XSLT en Apache Cocoon kan je er erg veel krachtige dingen mee doen. Veel dingen zoals XML -> pdf met behulp van xslfo zitten standaard in cocoon, waardoor je veel mogelijkheden hebt, waar de klant vaak naar vraagt.

Ik vraag mij eigenlijk af of er hier meer mensen zijn die met Cocoon werken?

Heb wel een halfslachtige poging gewaagd een paar jaar terug, maar afgehaakt om verschillende redenen, waaronder het feit dat alles dusdanig in XML verpakt zat dat ik het niet fijn meer vond werken. Daarnaast vond ik het traag en Java niet echt een geschikt platform voor mijn doeleinden.

Verder vind ik XML fijn. Blij met de XML/XSLT/DOM/SOAP toevoegingen/verbeteringen in PHP5. Gebruik het vooral voor XHTML templating, communicatie naar Flash clients toe en een beetje SOAP met third party backends.

===
Voor de PHPers die ook wel een soort Cocoon willen: Popoon

[ Voor 6% gewijzigd door Genoil op 20-01-2005 11:35 ]

[Onno]

Alarmnummer schreef op donderdag 20 januari 2005 @ 00:44:
Als jij dit beschouwt als een stuk gezeur dan is dat jouw probleem.

Nou, het lijkt me meer dat jij een probleem hebt. De meeste mensen die ik erover spreek hebben absoluut geen problemen met XML/XSL/enz. Natuurlijk moet je er even wat tijd in steken om het onder de knie te krijgen, maar dat geldt voor alles. Maar jij schijnt alles te willen kunnen gebruiken zonder er tijd in te steken. Dat kan dus gewoon niet. Als je er eens gewoon eens een dag of wat insteekt weet je het voor de rest van je leven en is dat ook weer opgelost. Dat is een stuk nuttiger bestede tijd dan gaan klagen dat het allemaal ruk is omdat je een geheugen als een zeef hebt en het telkens weer vergeet. Precies hetzelfde als bij de vorige thread van je die ik las.

Het kan handig zijn, maar XSLT is wel typisch weer zo'n taal die een XML syntax heeft en eigelijk is dat ook al iets totaal fouts.

In sommige gevallen is het inderdaad onhandig om XML te gebruiken, maar in het geval van XSLT vind ik dat zeker niet. Het heeft een duidelijke opzet en logisch gekozen elementen, ik heb er totaal geen problemen mee. Ja, het is hier en daar misschien net een tikkeltje abstrakter dan je favoriete imperatieve taal, maar daar moet je mee om kunnen gaan.

Ik weet niet of je het ook met Java hebt geprobeerd, maar het is daar alles behalve duidelijk.

Ja, dat gebruik ik ook in Java. En nee, ik heb er geen problemen mee.

Uiteraard. Ik heb ook geen problemen met XML als basis. Het scheelt weer een parser schrijven en je kunt eenvoudig data uitwisselen. Maar het gaat mij om alle technieken om XML heen. Voordat je ergens bent, ben je al 20 acroniemen tegengekomen.

Ik mag toch aannemen dat je op een wat geavanceerder niveau programmeert omdat je wel eens iets meer wilde dan GW-BASIC, omdat je het leuk vindt? Maar ik krijg de indruk dat je in feite totaal niet geinteresseerd bent in alle technieken, dat je alleen maar iets werkends wilt krijgen. Vind ik nogal merkwaardig voor iemand die daar z'n beroep van gemaakt heeft.

Niemand beweert dat XML qua implementatie simpel is.. het is simpel op andere punten: uitwisselbaarheid, uniformiteit, enz. Als je dat totaal onbelangrijk vindt moet je gewoon geen XML gebruiken.

Ik heb idd gezien dat er ergens Xerces/Xalan onderdelen in de JVM rondzweven. Maar als die zo goed zijn, waarom worden ze dan altijd nog een keer meegeleverd met distributies van allerlei tools (zelfs die voor 1.4 zijn gemaakt).

De versie van Xerces/Xalan verandert per JVM weer. Bij 1.5 zitten andere versies dan bij 1.4. Ik neem aan dat voor veel van die tools geldt dat de makers ervan geen zin hebben om een beetje portable te programmeren, zodat het met elke implementatie werkt, maar dat ze er gewoon vanuit willen kunnen gaan dat er een bepaalde versie gebruikt wordt. En dat kun je alleen bereiken door die versie stomweg mee te leveren.

[Soultaker]

Onno schreef op donderdag 20 januari 2005 @ 12:14:
Niemand beweert dat XML qua implementatie simpel is.. het is simpel op andere punten: uitwisselbaarheid, uniformiteit, enz. Als je dat totaal onbelangrijk vindt moet je gewoon geen XML gebruiken.

Volgens mij ging het niet zozeer om XML in theorie, maar meer de API's en libraries die wel beschikbaar zijn, maar niet handig werken.

Verder ken ik Alarmnummer wel als iemand die juist moeite doet om code te schrijven die goed in elkaar steekt, de juiste technieken gebruikt, gerefactored wordt wanneer er nog wat te verbeteren valt, enzovoorts. Maar juist voor iemand die een beetje perfectionistisch is ingesteld is het vervelend als je een simpel probleem met 10.000 regels code en 10 verschillende documenten moet oplossen.

Uiteindelijk is het voor interoperabiliteit van grote systemen namelijk juist van belang dat de onderliggende systemen zo simpel mogelijk zijn. XML is een simpel en krachtig bestandsformaat, maar als dat niet praktisch benaderd kan worden, verdwijnen die voordelen. Dan kun je bijna weer beter een eigen binary of plain text formaat verzinnen.

[Alarmnummer]

Onno schreef op donderdag 20 januari 2005 @ 12:14:
[...]

Nou, het lijkt me meer dat jij een probleem hebt. De meeste mensen die ik erover spreek hebben absoluut geen problemen met XML/XSL/enz.

De meeste mensen die ik spreek hebben er juist wel problemen mee. Vaak zijn het erg triviale zaken die zo opgelost zijn als je maar bij de juiste documentatie kunt komen.

Dat kan dus gewoon niet. Als je er eens gewoon eens een dag of wat insteekt weet je het voor de rest van je leven en is dat ook weer opgelost. Dat is een stuk nuttiger bestede tijd dan gaan klagen dat het allemaal ruk is omdat je een geheugen als een zeef hebt en het telkens weer vergeet. Precies hetzelfde als bij de vorige thread van je die ik las.

Api`s moeten simpel in gebruik zijn voor simpele zaken.. Wil je meer dan moet het kunnen en dan moet je met de complexiteit in aanraking komen. Dat is exact hetzelfde probleem als ik bij java io zie.

In sommige gevallen is het inderdaad onhandig om XML te gebruiken, maar in het geval van XSLT vind ik dat zeker niet. Het heeft een duidelijke opzet en logisch gekozen elementen, ik heb er totaal geen problemen mee. Ja, het is hier en daar misschien net een tikkeltje abstrakter dan je favoriete imperatieve taal, maar daar moet je mee om kunnen gaan.

Het is niet de abstractie waar ik problemen mee heb, maar het te lang zoeken naar een simpele oplossing.

Ik mag toch aannemen dat je op een wat geavanceerder niveau programmeert omdat je wel eens iets meer wilde dan GW-BASIC, omdat je het leuk vindt? Maar ik krijg de indruk dat je in feite totaal niet geinteresseerd bent in alle technieken, dat je alleen maar iets werkends wilt krijgen. Vind ik nogal merkwaardig voor iemand die daar z'n beroep van gemaakt heeft.

Ik ben zeker wel geinteresseerd in technieken. Maar als ik een bepaald probleem moet oplossen (en me daarvoor moet concentreren op een of meerdere technieken), dan heb ik geen zin om ook nog eens een enorme lading tijd kwijt te zijn aan andere technieken.

Ik ben op dit moment bv veel bezig met Lucene (een indexeer machine voor Java). Een geweldig systeem. Ik ben wat van mijn boeken aan het indexeren en daarvoor spreek ik de webservices van Amazon aan. Ok..tot zover allemaal prachtig. Maar als ik dan een aantal dagen kwijt ben om informatie af te trekken van Amazon terwijl het principe extreem eenvoudig is.. tja.. dan raak ik geirriteerd.

Ik vind het dus niet erg om diep in een of ander systeem te duiken. Maar ik heb geen zin om ook nog een diep in andere systemen te gaan duiken terwijl ik daar maar iets simpels nodig ben.

Niemand beweert dat XML qua implementatie simpel is.. het is simpel op andere punten: uitwisselbaarheid, uniformiteit, enz. Als je dat totaal onbelangrijk vindt moet je gewoon geen XML gebruiken.

Het probleem is dat je er soms niet om heen kan, bv webservices. En dan heb ik er nog geen probleem mee, als mijn tools het maar goed doen. Maar als Axis bv eruit blijft klappen met classcasts exceptions en mij geen goeie alternatieven worden aangeboden, dan heb ik geen goeie tools om het probleem op te lossen.

Ik heb uiteindelijk maar besloten om REST queries uit te voeren, en uit de terug gestuurde XML gewoon met XPath queries de juiste info trekken. Dit had ik in 30 minuten voor elkaar!!

Als je kijkt naar .NET dan is het een stuk duidelijker..

[ Voor 5% gewijzigd door Alarmnummer op 20-01-2005 12:53 ]

[Kwistnix]

Ik heb wel een beetje ervaring met Java en XML en ik moet zeggen dat het met JDOM in één keer goed ging. Erg simpel vond ik het zelfs. En in tegenstelling tot wat je zou verwachten met een naam als JDOM kan er gebruik gemaakt worden van SAX parser of een DOM parser.

Ik moest voor mijn opleiding een Java applicatie maken die zijn data naar een bestand kon lezen en er naar schrijven. Toen heb ik voor XML gekozen. Een DOM tree gemaakt, een subklasse van TreeModel geschreven en die gekoppeld aan de JTree in m'n GUI. Het bestand wordt uitgelezen, er wordt een DOM tree van gebouwd, vervolgens wordt er een DOMTreeModel aangemaakt en die wordt dan in de Jtree weergegeven. Als je de Tree dan wilt opslaan gaat het in de omgekeerde richting. Super handig.

[ Voor 7% gewijzigd door Kwistnix op 20-01-2005 13:50 ]

[Redshark]

Het laatste jaar zit ik regelmatig in de XML/XSLT en ik ben er blij mee
Ik ben niet een die-hard programmeur die de Java-code schrijft voor ons CMS, dat doet (gelukkig) iemand anders. Deze zelfde persoon heeft gekozen voor een gemakkelijk datamodel wat erg flexibel is in gebruik.
Hierdoor krijg ik een (inmiddels) bekende structuur in de XML die deze applicatie weer uitspuugt en kan ik hier lekker mee spelen. Langzaam aan ben ik er steeds handiger in geworden en inmiddels ben ik er tevreden mee.
Verder doen Apache/Tomcat/Xalan het allemaal okay en heb ik er zelf weinig problemen mee. De programeur heb ik nog nooit hardgrondig horen vloeken hierover dus dat gaat ook lekker.
Xalan is wel een absolute eis geworden hier (of een vergelijkbaar iets, Xerces). Af en toe krijg ik(als Xalan niet aan staat) zo'n berg XML naar mijn browsertje toe geworpen dat het ding er vol goede moet uitklapt. Niet fijn als je complexe transformaties gaat maken. Meestal zet ik hem dan snel aan

[TukkerTweaker]

Ben ook niet zo blij met XSLT. Wel met xalan/xerces die ik beide gebruik voor DOM, maar vooral de transformatie naar (in mijn geval) PDF met is erg onduidelijk. Ik maak gebruik van FOP en docbook-xsl, maar de documentatie houd niet over. Het is vaak trail and error.

[riezebosch]

Onno schreef op donderdag 20 januari 2005 @ 12:14:
[...]

Ehm... Nu wil ik niet Alarmnummer een hand boven het hoofd houden, maar ik vind persoonlijk deze topics wel heel wat interessanter dan de gemiddelde programmeervraag-topics! Juist door te delen waar hij tegenaan loopt komen er interessante dingen op tafel. Zo had ik bijvoorbeeld nog nooit van Singleton en Design Patterns in het algemeen gehoord, maar heb ik nu eindelijk toch maar het GoF boek gekocht, en herken ik opeens veel meer dingen in zulke topics

[drm]

Alarmnummer:
Ik heb geen problemen met het idee achter XSLT, maar wel met de syntax.

Maar die is niet eens heel erg uitgebreid. Je bouwt voort op de syntax van XML (XSLT heeft strict genomen natuurlijk geen eigen syntax) en verder moet je gewoon een goede reference hebben van de beschikbare elementen. 't Non-imperatieve denken kan het begin wel even lastig zijn, maar dat is meer een opstartprobleem.

Humans should not have to grok XML

In dat artikel lees ik eigenlijk niet heel veel meer dan "XML is niet zaligmakend". Daar ben ik het mee eens. Je moet niet XML gaan gebruiken voor zaken waar het niet geschikt voor is, maar ik snap niet zo goed waarom dat jouw standpunt zou onderbouwen. Ik snap eigenlijk uberhaupt niet zo goed wat je standpunt is. Gaat het je nou om XML en alle aftakkingen en uitwassen daarvan, of gaat het je om de poor documented en/of halve implementaties in Java?

[Verwijderd]

The Church of XML

[Alarmnummer]

drm schreef op donderdag 20 januari 2005 @ 18:09:
[...]
Maar die is niet eens heel erg uitgebreid. Je bouwt voort op de syntax van XML (XSLT heeft strict genomen natuurlijk geen eigen syntax)

Het heeft wel degelijk een syntax. De syntax van XSLT is een subset van die van XML.

en verder moet je gewoon een goede reference hebben van de beschikbare elementen. 't Non-imperatieve denken kan het begin wel even lastig zijn, maar dat is meer een opstartprobleem.

Mwuah... het non imperatieve dingen daar heb ik geen problemen mee, check bv mijn prolog gebazel.

En het is verder niet alleen XSLT, maar gewoon de hele bende van technieken. Zoeken.. zoeken zoeken.. onduidelijk onduidelijk... en na een uur zoeken nog geen antwoord op je vragen. Als dit keer op keer gebeurt dan krijg je toch een wrang gevoel erbij... en dat gevoel heb ik dus met XML gerelateerde technieken (en het Java platform). En ik ben verder niet een totale noob op het gebied van XML en dit is dus zeker niet mijn eerste aanvaring. Er zijn gewoon bepaalde systemen die prettig werken.. en er zijn systemen die dat niet doen.

Ik snap eigenlijk uberhaupt niet zo goed wat je standpunt is. Gaat het je nou om XML en alle aftakkingen en uitwassen daarvan, of gaat het je om de poor documented en/of halve implementaties in Java?

Het is een combinatie van: brakke tools, slechte documentatie, niet de mogelijkheid om snel antwoord te krijgen op relatief eenvoudige zaken. En de ontwikkeling van XML zit niet stil, dus als je ergens iets moet doen, zul je gewoon veel verschillende zaken voor de kiezen krijgen en die vind ik in veel van de gevallen niet de moeite waard. Het idee erachter is goed... alleen kost het mij in de praktijk te veel tijd.

Verwijderd schreef op donderdag 20 januari 2005 @ 19:28:
The Church of XML

Hmm tja.. Ik kan het niet echt serieus nemen. XML zal in veel systemen maar een fractie zijn (data uitwisseling/document generatie) en imho ook niet bijster interessant welke techniek je nu eigelijk gebruikt aangezien je het vaak toch wegabstraheerd. Dus tja...

[ Voor 26% gewijzigd door Alarmnummer op 20-01-2005 20:36 ]

[Verwijderd]

Alles leuk en aardig Alarmnummer, maar elke thread die je start is negatief. vind je ook wel eens iets (in dit vakgebied) domweg goed?

[Alarmnummer]

Verwijderd schreef op donderdag 20 januari 2005 @ 21:12:
Alles leuk en aardig Alarmnummer, maar elke thread die je start is negatief.

Ik adviseer je dan mijn post history eens te gaan checken.

vind je ook wel eens iets (in dit vakgebied) domweg goed?

Zekers.. check bv mijn spring rants, mijn pattern geblaat.. en mijn prolog gebazel

[ Voor 7% gewijzigd door Alarmnummer op 20-01-2005 21:29 ]

[drm]

Alarmnummer:
Het heeft wel degelijk een syntax. De syntax van XSLT is een subset van die van XML.

Naja, goed, 't is maar hoe je het formuleert

Mwuah... het non imperatieve dingen daar heb ik geen problemen mee, check bv mijn prolog gebazel.

't Was ook meer een algemene opmerking hoor

En het is verder niet alleen XSLT, maar gewoon de hele bende van technieken. Zoeken.. zoeken zoeken.. onduidelijk onduidelijk... en na een uur zoeken nog geen antwoord op je vragen. Als dit keer op keer gebeurt dan krijg je toch een wrang gevoel erbij... en dat gevoel heb ik dus met XML gerelateerde technieken (en het Java platform). En ik ben verder niet een totale noob op het gebied van XML en dit is dus zeker niet mijn eerste aanvaring. Er zijn gewoon bepaalde systemen die prettig werken.. en er zijn systemen die dat niet doen.

true.

Het is een combinatie van: brakke tools, slechte documentatie, niet de mogelijkheid om snel antwoord te krijgen op relatief eenvoudige zaken. En de ontwikkeling van XML zit niet stil, dus als je ergens iets moet doen, zul je gewoon veel verschillende zaken voor de kiezen krijgen en die vind ik in veel van de gevallen niet de moeite waard. Het idee erachter is goed... alleen kost het mij in de praktijk te veel tijd.

't Is dus vooral de optelsom, begrijp ik. Daar kan ik me wel in vinden ja

[Alarmnummer]

En nogmaals.. ik heb geen hekel aan XML in het geheel. Als ik morgen naast mijn bed het "maak Alarmnummer blij met XML" boek vind waarin ik 90% van de vaak voorkomende problemen mee kan oplossen, ga ik misschien ook wel op de grote martk in Groningen, xml aan iedereen verkondigen.. Maar zo lang ik dat boek niet heb... te lang moet blijven bladeren naar in principe eenvoudige zaken, dan vind ik veel XML gerelateerde technieken toch een vrij groot risico. (En daarbij doel ik dus niet op eenvoudig XML/Schema gebruik)

Tijd = geld..

[ Voor 8% gewijzigd door Alarmnummer op 20-01-2005 21:49 ]

[LAN]

Ik ben net een dag bezig geweest om een koppeling te maken met de Microsoft MapPoint webservice vanaf een Java client.

M'n collega gebruikte daarvoor Axis wat inderdaad nogal wat haken en ogen heeft.

Omdat ik geen kennis van het principe SOAP had ben ik op een lager niveau bezig geweest. Het WSDL bestand doorspitten om de juiste functie aanroepen met bijbehorende argumenten te achterhalen. Daarna zelf SOAP calls maken, dus HTTP POSTs met digest authenticatie en vervolgens een SOAP envelope als payload meegeven. En daarna de reactie van de webservice server opvangen.

Het werkt fantastisch moet ik zeggen, en de onderliggende techniek, waar XML een belangrijk onderdeel van is, is logisch, goed te volgen.

Dus, het XML gedeelte, daar ben ik wel over te spreken.

[Blue-eagle]

Terwijl ik dit type heb ik 8 XSL bestanden openstaan, 4 ASP pagina's, en 1 XML file. Alles in de systemen waar we mee werken op de zaak heeft te maken met XML. Ik kan me serieus geen makkelijkere manier voorstellen om te doen wat we doen: web-based applicaties bouwen. XML is gestructureerd, XML is leesbaar, XML is simpel.

Wat betreft XSL, de structuur en de werking zijn niet makkelijk te begrijpen als beginner (op XSL gebied!) maar het is zo enorm krachtig. Het wordt hier voornamelijk gebruikt als Template systeem - converteer recordset naar XML, gooi XML tegen XSL - voila: HTML.
Variabelen, loopjes, include files, alles werkt zo verschrikkelijk makkelijk.

Het is erg simpel, koop gewoon een boekje over XML/XSL en leer de basics, daarna kom je in combinatie met Google snel erg ver in het gebruik van deze twee.

De implementatie van Java ken ik verder niet.. Maar als je java programmeur bent moet het leren van XSL een eitje zijn.

[EfBe]

Ik vind het idee achter xml wel aardig, dat het voor veel te veel dingen gebruikt wordt (door hype en andere crap) en dat de tools veel te kort schieten, met name API's voor in-memory xml. ga maar eens nodes managen in een geladen Xml dom in .NET bv. Node toevoegen? Niet zoals bij alle andere Node collections in de .NET API, nee, via een obscure crap-api bedacht door de airheads van W3C... Een node toevoegen aan een xml file op disk? veel plezier

[flowerp]

Nu is het zo dat XML in de eerste instantie een universele data uitwisselings taal is, maar hoe staan de mensen hier nu tegenover het gebruik ervan als programmeertaal?

Hierboven hoorde ik wel wat negatieve geluiden hierover, maar daar werd niet echt verder op in gegaan.

Zelf kom ik XML als programmeertaal in tenminste 3 situaties tegen:

-Imperatief, zoals in JSP pagina's (zoals JSTL en andere taglibs). Hier wordt het gebruikt van Java scriptlets juist ontraden en ligt de nadruk echt meer op het gebruik van XML.

-Task based, zoals in ANT. De meningen zullen wel verschillen of dit programmeren is of niet, maar ik zie toch echt een aantal executeerbare 'dingen' die neergezet worden in XML, inclusief afhankelijkheden en volgorde.

-Dataflow based; het aan elkaar knopen van filters en (data) pipes in een graaf structuur zoals een dag of een tree. Behalve bij een pipeline, geeft dit een vrijere manier van programmeren omdat je feitelijk alleen de graaf opstelt. Aan de hand van de initieele afhankelijkheden en tijdens de runtime de overblijvende afhankelijkheden, wordt de volgorde van uitvoeren bepaald.

Natuurlijk wil je vooral in het laatste geval ook graag beschikken over een grafische editor (graven zijn nu eenmaal het makkelijkst visueel), maar als zo'n editor dan naar XML wegschrijft en ook handgeschreven (of aangepaste) XML inleest heb je best of both worlds.

[Alarmnummer]

flowerp schreef op zaterdag 22 januari 2005 @ 14:57:
Nu is het zo dat XML in de eerste instantie een universele data uitwisselings taal is, maar hoe staan de mensen hier nu tegenover het gebruik ervan als programmeertaal?

Ik ben er dus erg op tegen. En XML kun je niet gebruiken als programmeertaal. XML an sich is niets. Intern worden normale structuren opgebouwd die je ook met een 'echte' taal (lees een taal op maat en niet een generieke taal zoals XML) voor elkaar had kunnen krijgen. Het is erg onwaarschijnlijk dat jij beter kunt programmeren in een XML gebaseerde taal ipv een op maat gemaakte domein taal.

code:

<if>
 <condition><expr><var>x</var><operator></operator><const>10</const></condition>
     <statement><call><function>exit</function></call></statement>
</if>

of

code:

if(x>10)
    exit();

XML gebaseerde programmerentalen zijn in 90% van de gevallen dommer dan dom. Je loopt rechtstreeks een AST op te bouwen.. we kunnen dan net zo goed terug gaan naar het LISP tijdperk.

Je moet dus een onderscheid maken tussen de werking en de invoer. XML gebaseerde invoer is vaker minder prettig te lezen.

[ Voor 8% gewijzigd door Alarmnummer op 22-01-2005 19:16 ]

[flowerp]

Alarmnummer schreef op zaterdag 22 januari 2005 @ 16:25:
[...]

Ik ben er dus erg op tegen. En XML kun je niet gebruiken als programmeertaal. XML an sich iets niets.

Dat is waar. Heel basic gezegd is XML zelf niets meer dan je hebt een openings tag waarbij attributen kunnen horen, en een afsluit tag. Daartussen kunnen weer tags staan of platte tekst.

Waar het hier natuurlijk gaat is een XMl dialect: de specificatie die aan bepaalde tags en hun combinatie (context) semantiek toekent. In dat geval is het meer het ontwerp van dat specfieke dialect dat speelt, dan XML ansich.

Voor mijn eerste geval, imperatief gebruik, ben ik ook niet helemaal overtuigd. Daar voldoet traditionele C achtige syntax toch het best. Voor mijn dataflow voorbeeld vind ik XML wel weer heel geschikt. Probeer dat maar eens met C achtige syntax te schrijven. Kan natuurlijk wel, maar dan vind ik XML toch makkelijker leesbaar. Plus dat XML makkelijker door tools (in geval dataflow taal) gevisualiseerd kan worden.

(voor hele eenvoudige graphs kun je overigens ook iets zoals de .DOT syntax gebruiken, die is heel beknopt, maar als je met named poorten werkt per filter en die wilt kopellen is XML weer makkelijker kwa syntax)

[Infinitive]

Mwa, voor de "dataflow" manier weet ik wel een betere domain specific language... diagrammen.

[flowerp]

Infinitive schreef op zaterdag 22 januari 2005 @ 20:32:
Mwa, voor de "dataflow" manier weet ik wel een betere domain specific language... diagrammen.

Klopt! Een diagram is het meest handige. In een textuele beschrijving 'zie' je de samenhang van het geheel niet. Echter, een diagram moet toch ook eens opgeslagen worden. Hoe doe je dit? Binair kan, maar XML is dan wel heel handig. Design het serializable formaat dan een beetje human-friendly en je kan zowel op text niveau werken als grafisch.

Text niveau kan heel handig zijn als je snel search en replace veranderingen wil doen over de hele dataflow. Voor sommige mensen kan het ook sneller gaan of in aparte nodes (filters) iets in tekst te veranderen dan grafisch. In beide gevallen is XML een uitkomst.

[Soultaker]

Wel jammer dat XML weer zo'n ongeschikt formaat is voor het opslaan van graafstructuren (wat een diagram meestal is). Dan moet je gaan rommelen met node identifiers en daarnaar verwijzen, maar dan verdwijnt wel het voordeel van de hiërarchische structuur van HTML.

[flowerp]

Soultaker schreef op zondag 23 januari 2005 @ 01:32:
Wel jammer dat XML weer zo'n ongeschikt formaat is voor het opslaan van graafstructuren (wat een diagram meestal is). Dan moet je gaan rommelen met node identifiers en daarnaar verwijzen, maar dan verdwijnt wel het voordeel van de hiërarchische structuur van HTML.

Maar een identifier voor je nodes heb je toch altijd nodig? Dat is onafhankelijk van je taal.

code:

#nodes
A,B,C
#edges
A->B
A->C
B->C

Ik ontkom er niet aan om mijn nodes een ID (of unieke naam) mee te geven. Dat heeft de wiskundige beschrijving ook.

Bovenstaande syntax werkt makkelijk voor simpele diagrammen, waarbij de edges direct gedefinieerd worden.Stel nu dat ik iniedergeval een aantal vaste ingaande en uitgaande 'kanalen' heb per node. Dit is onafhankelijk van of daar een verbinding (edge) aan hangt of niet tevens is voor elk kanaal een datatype gespecificeerd. Nu wordt de simpele notatie al wat lastiger. Ik heb namelijk echt een 'interface' voor mijn nodes nodig. Mischien zou ik C actige syntax kunnen gebruiken, maar XML is dan net zo makkelijk.

[Soultaker]

Mijn punt was dat het voordeel van de hiërarchische structuur van XML verloren gaat als je er graafstructuren in op probeert te slaan, omdat XML zich beperkt tot boomstructuren.

XML had qua structuur een voordeel ten op zichte van comma seperated values, namelijk dat een boomstructuur gemaakt wordt door elementen 'binnen' andere elementen te definiëren. Een csv-bestand ziet bijvoorbeeld zo uit:

code:

id,parentid,name,somevalue
0,,foo,52712.81
1,0,bar,93901.85
2,1,baz,466789.10
3,1,quux,8456.50

In de meeste applicaties zijn de identifiers onbelangrijk; ze duiden alleen maar op de structuur (die niet ontzettend duidelijk is in het vorige voorbeeld). In XML zou je zo'n boom duidelijker kunnen definiëren:

code:

<tag name="foo" somevalue="52712.81">
    <tag name="bar" somevalue="93901.85">
        <tag name="baz" somevalue="466789.10" />
        <tag name="quux" somevalue="8456.50" />
    </tag>
</tag>

De hiërarchie is zo veel duidelijker en je hebt geen node identifiers meer nodig! Bovendien kun je in bijvoorbeeld een DOM-tree heel makkelijk een deelboom verwijderen, om maar wat te noemen.

Als je echter een graaf wil maken, moet je inderdaad los de nodes en de edges specificeren. De XML syntax is dan helemaal niet meer helderder dan een ouderwetse relationele structuur. Natuurlijk heeft XML dan nog wel een boel voordelen (verschillende soorten data in één bestand, goed gedefinieerde karaktercodering en escaping), maar het voordeel is minder duidelijk dan met een boomstructuur.

[flowerp]

Ik snap nu wel wat je bedoelt. Je kunt de graaf niet uitdrukken door de natuurlijke ordering van elementen (tags) te gebruiken, zoals je dat wel bij een tree kunt doen.

Inderdaad, bij het serializen van een graph heb je in eerste instantie gewoon een losse (niet geneste) set van nodes en edges. Een andere syntax dan XML kun je daar in principe ook voor gebruiken.

XML gebruik je in dit geval wel 'natuurlijk' door verschillende entiteiten te nesten. Je kunt je bijvoorbeeld voorstellen dat je een sectie maakt met de nodes definities/interfaces en een andere sectie met de edges. Voorderest kun je nodes wel logisch groupen waarbij je weer wel de nesting van tags gebruikt.

Ook kun je veel makkelijker optionele elementen toevoegen die bepaalde tools kunnen negeren. Bij een dataflow denk ik aan bijvoorbeeld een description en icon attribuut of tag waar een execution engine niks aan heeft, maar die een grafische editor juist wel wil verwerken.

Voorderest is XML niet alleen nesting. Zoals je zelf zegt, er zijn ook andere dingen. Het gebruik van attributen kan ook gewoon makkelijk zijn. Als je naar de .DOT syntax kijkt dan is dat voor de specificatie van edges zeker makkelijker en duidelijker als XML, maar als je dan naar de definitie van complexe nodes kijkt wordt het weer minder. Zie dit standaard voorbeeld waarbij je nog niets eens datatypes voor de poorten opgeeft en of ze verplicht of optioneel geconnect moeten worden (dat is buiten het domain van DOT maar het gaat even op de syntax). Het volgende is zeker korter dan het in XML zou kunnen, maar of het duidelijker is?

code:

digraph structs {
   node [shape=record];
   struct1 [shape=record,label="<f0> left|<f1> middle|<f2> right"];
   struct2 [shape=record,label="<f0> one|<f1> two"];
   struct3 [shape=record,label="hello\nworld |{ b |{c|<here> d|e}| f}| g | h"];
   struct1:f1 -> struct2:f0;
   struct1:f2 -> struct3:here;
}

Voor mij ligt ook een beetje het verschil tussen het feit of de graph code voornamelijk gelezen moet worden of voornamelijk geschreven. Als het door tools gegenereerd wordt, af en toe gelezen wordt door mensen en incidenteel geschreven wordt door mensen dan zou ik voor XML kiezen.

Ook speelt de ontwikkel tijd mee. XML parsers heb je al; je zet zo een eigen taaltje (dialect) op. Met Bison/Flex kun je ook wel snel parsers voor andere grammars maken hoor, maar het duurt toch allemaal wat langer.