[web] Is transformatie "here to stay"

[Verwijderd]

Ik heb nu wat gespeeld met XML/XSL. Maar als ik om me heen kijk wordt het nauwelijks gebruikt. Een site als GoT zou bijv. ook wel met transformaties gemaakt kunnen worden. Ik zie echter wat nadelen:
1-Te moeilijk
2-Onbekend (PHP werkt toch ook?)
3-Performance (XSL schiet tot nu toe niet echt op)

Zijn er ook andere mensen real-world met dit bezig?

[whoami]

Bedoel je waarom er geen sites zijn die mbhv XML/XSL gemaakt zijn?

XML is toch eerder een middel om gegevens uit te wisselen en niet bedoeld om sites mee te gaan bouwen.

[Verwijderd]

Het voordeel van xml & xsl is dat je bvb je database (sql server in ieder geval) puur xml kan laten uitpoepen en dit snel omzetten. Door gelijk xml uit je database te zuigen heb je tijdswinst.

Op de Microsoft DevDays werd trouwens verteld dat de komende versie van MS SQL Server compleet op xml gebaseerd zal worden en dus nog beter te combineren zal zijn met xml.

Dus... dan weet je dat ook weer.

succes rbn

[Verwijderd]

xml idd DE techniek als je het over webservices hebt...

rbn

[mbravenboer]

Doekman: Ik heb nu wat gespeeld met XML/XSL.

Leuk

Maar als ik om me heen kijk wordt het nauwelijks gebruikt. Een site als GoT zou bijv. ook wel met transformaties gemaakt kunnen worden.

Een XML+XSL gebaseerd forum zou inderdaad fantastisch zijn omdat je dan ook direct te data kan benaderen. Dat GoT dit niet doet komt meer door de ouderdom van de software en de keuzes van de originele makers.

1-Te moeilijk

Goed punt.

2-Onbekend (PHP werkt toch ook?)

Bij een XML+XSL oplossing is er een duidelijke scheiding tussen de data van een website, welke in XML beschikbaar is, en de mogelijke views op deze data, die met XSL gecreeerd kunnen worden. Een XML+XSL oplossing biedt op dit punt veel meer mogelijkheden dan een PHP oplossing. Het is dan echter wel een noodzaak dat er ook daadwerkelijk behoefte is aan een scheiding. Als een scheiding niet nodig is, is een XML+XSL oplossing ook veel minder aantrekkelijk. Een scheiding is noodzakelijk als:
- andere partijen de data ook willen kunnen gebruiken
- verschillende views worden aangeboden: wap, html, printable, text-based, pdf enz.

3-Performance (XSL schiet tot nu toe niet echt op)

Dat hangt volledig van de gebruikte engine af. XSL stylesheets kunnen op verschillende manieren worden gebruikt:
1. Interpreteren van de stylesheet bij elke transformatie
2. Cachen van een 'Transformer' at runtime, waardoor niet steeds de XSL file opnieuw geparsed hoeft te worden.
3. Compileren van een XSL stylesheet naar uitvoerbare code.

Ik gebruik zelf vaak oplossing (2) met Apache's Xalan en de performance daarvan vind ik uitstekend. Oplossing 3 zou nog veel meer mogelijkheden bieden omdat je dan ook leuke optimalisaties kan gaan toepassen, zeker als er een XML Schema of DTD beschikbaar is. Apache is hier ook mee bezig. Ze hebben de XSLT Compiler van Sun een tijdje geleden kado gekregen.

Zijn er ook andere mensen real-world met dit bezig?

Tja, ik gebruik het wel, maar op kleinere schaal. Ik gebruik het ook veel in 'gewone' applicaties. Af en toe moet ik weleens een website met wat resultaten, waarvoor ik ook altijd XML+XSL gebruik.

http://www.javahova.net zal volledig XML+XSL gebaseerd zijn.

Of transformatie een blijvertje is?

Deze vraag zou ik eigenlijk het liefste indirect beantwoorden: is XML een blijvertje? Jazeker: het aanbieden van data in de vorm van XML is nu al vaak de praktijk en zeker de toekomst. Voor uitwisseling van data is XML zeker de praktijk en de toekomst. Vaak zal je data echter willen combineren of van structuur wijzigen. Hiervoor is XSLT de perfect oplossing.
Ik denk wel dat het belangrijkste voordeel van XSLT ook gelijk het grootste nadeel zal worden. XSLT is relatief eigenlijk een vrij eenvoudige taal. De opzet van XSLT is vrij duidelijk te begrijpen. De kracht van XSLT is naar mijn mening echter vooral te danken aan XPath en de gedachte structurele recursie. XSLT zelfs stelt verder niet zoveel voor. Complexere transformaties zijn vaak niet uit te drukken of worden zeer complex. De grootste beperking is naar mijn mening dat output, output is. Je kan nooit op een deelresultaat van je transformatie nog een keer wat transformaties toepassen.

Daarom zie ik eigenlijk ook een toekomst voor de betere transformatie-talen. Het model van XSLT zal niet aangepast worden en dus zal het nooit voldoen voor alle complexe transformaties. Op het moment ben ik vrij druk bezig met Statego (zie mijn sig). Stratego is een uitermate krachtige transformatie-taal die veel meer functionaliteit biedt (uiteraard tegen de kosten van complexiteit). Stratego heeft veel betere mogelijkheden om herhaald transformaties toe te passen, de traversal door de structuur te bepalen en informatie tijdens de traversal door te geven en te verzamelen. Stratego werkt met een vergelijk universeel data-type als XML: ATermen. Op dit moment ben ik samen met de hoofd-ontwikkelaar van Stratego bezig een brug te maken tussen ATermen en XML. Je kunt dan Stratego gebruiken om XML te transformeren. Stratego compileert op dit moment naar C-code en is mede daardoor behoorlijk snel .

whoami: XML is toch eerder een middel om gegevens uit te wisselen en niet bedoeld om sites mee te gaan bouwen.

Waarom? Je kan content in XML vorm opslaan. Deze content kan je omzetten naar HTML op precies dezelfde manier zoals nu relationele data uit databases wordt omgezet naar HTML.

[mbravenboer]

Ik denk trouwens dat veel sites al niet zichtbaar XSL gebruiken. Je kan op dit moment uiteraard niet vertrouwen op client-side transformatie (en het is de vraag of je dat ooit zult kunnen doen).

Ik zat een tijdje geleden een in de source van IBM pagina te kijken, waar ik in een HTML document een namespace declaratie van XSLT tegenkwam. Uiteraard werd in de pagina zelf nergens XSLT gebruikt . Veel engines zijn een beetje slordig in het achterlaten van namespace verwijzingen, dus ik vermoed dat hier server-side XSL werd toegepast.

[Orphix]

mbravenboer, je zegt dat je een betere toekomst ziet voor andere transformatie talen. Nu vraag ik mij af in hoeverre XSLT niet voldoet waar andere talen dat wel kunnen.

Ik geloof dat er namelijk veel meer gebruikers/programmeurs zijn die XML data naar HTML willen transformeren dan programmeurs die de XML output van MS SQL server recursief en omgedraaid alfabetisch gesorteerd op id nummer naar Oracle XML output willen transformeren. (dit is een fictief onderwerp he )

Ik weet dat je inmiddels toch wel XML expert mag worden genoemd , maar vraag me af of je zelf maatstaf bent voor de gemiddelde (transformatie) programmeur.
Je kan het een beetje vergelijken met talen als C++ en VB en PHP. C++ staat er bekend om dat het krachtiger is dan VB maar beiden hebben 'de toekomst'. Nu ben ik niet zo'n transformatie expert, maar ik kan dus niet zo snel iets bedenken waarbij je enorm geavanceerde transformatie nodig hebt?
Dus: is het praktisch gezien logisch/nuttig om veel tijd en moeite te stoppen in een moeilijkere transformatie taal?

[brammetje]

Ja, wij zijn met www.javahova.net hiermee bezig. Het word al met al een leuk systeempje, en jullie kunnen ook een keer een uitgebreide uitleg krijgen van je hoe je leuk een site met xml en xslt op kan zetten..

edit: maar daar zijn we nog eventjes niet aan toe

[mbravenboer]

Orphix: mbravenboer, je zegt dat je een betere toekomst ziet voor andere transformatie talen. Nu vraag ik mij af in hoeverre XSLT niet voldoet waar andere talen dat wel kunnen.

Het grootste probleem van XSLT is naar mijn mening de 'definitieviteit' (vaag woord, zal vast niet bestaan ) van de output: je kunt geen transformaties toepassen op een tussen-resultaat. Uiteraard kan je wel meerdere stylesheets over een file halen, maar dat bedoel ik ook weer niet helemaal .

Ik geloof dat er namelijk veel meer gebruikers/programmeurs zijn die XML data naar HTML willen transformeren dan programmeurs die de XML output van MS SQL server recursief en omgedraaid alfabetisch gesorteerd op id nummer naar Oracle XML output willen transformeren.

LOL, Hehe . Wat ik bedoelde: het is absoluut niet ingewikkeld om een schijnbaar vrij eenvoudige transformatie te verzinnen die enorm lastig of onmogelijk in XSLT te beschrijven is. Hierbij gaat het vooral om het verzamelen van gegevens en het opslaan van deze gegevens voor een verder punt in de transformatie. Ook worden stylesheets snel onnodig complex omdat je niet componenten kunt werken: output = output. Als output niet zo definitief was, zou je je transformatie beter kunnen verdelen in een aantal componenten.

maar vraag me af of je zelf maatstaf bent voor de gemiddelde (transformatie) programmeur.

Daar heb je op zich wel gelijk in, maar je het is helaas mijn vak om niet alleen zoals in de praktijk na te denken over wat gemiddeld nodig is .

Maar, een transformatie hoeft niet gelijk ultiem complex te zijn om lastig uitdrukbaar te zijn in XSLT. Ik heb het niet over ultra-ingewikkelde constructies . Overigens: ik ben een groot fan van XSLT en zou ook in heel veel gevallen het gebruik ervan aanmoedigen (het staat niet voor niets in mijn sig ). Wel is het goed om na te denken voor wat voor soort transformaties XSLT nu echt geschikt is. XSLT is vooral geschikt voor herstructurering en het combineren van verschillende bronnen. Zodra er wat verbanden gezocht moeten worden in een XML bestand ontstaan er problemen...

Dus: is het praktisch gezien logisch/nuttig om veel tijd en moeite te stoppen in een moeilijkere transformatie taal?

Mwah, het zou denk ik wat kortzichtig zijn om XSLT te accepteren als het best haalbare. Stratego zal zeker niet de transformatie-taal worden, maar het is een interessant onderzoek naar wat er mogelijk moet zijn in een transformatie-taal. In de toekomst zullen er dan zeker weten opvolgers van XSLT komen meer mogelijk maken, maar makkelijk maken wat in Stratego nu soms nog moeilijk is . Overigens worden er ook features van XSLT in Stratego opgenomen .

[Verwijderd]

haha, ik dacht al, transformatie is het stokpaartje van Martin, maar zo'n uitgebreide reactie had ik niet verwacht.

Op maandag 17 december 2001 22:32 schreef mbravenboer het volgende:
[...]
Dat hangt volledig van de gebruikte engine af. XSL stylesheets kunnen op verschillende manieren worden gebruikt:
1. Interpreteren van de stylesheet bij elke transformatie
2. Cachen van een 'Transformer' at runtime, waardoor niet steeds de XSL file opnieuw geparsed hoeft te worden.
3. Compileren van een XSL stylesheet naar uitvoerbare code.

Optie 3 wordt wel bij content-management systemen gebruikt. De content wordt in XML beheerd. Bij inchecken in versie-beheer-systeem wordt het getransformeerd naar HTML (gebeurd bij delen van de microsoft-site).

http://www.javahova.net zal volledig XML+XSL gebaseerd zijn.

maar is het nog niet

is XML een blijvertje? Jazeker: het aanbieden van data in de vorm van XML is nu al vaak de praktijk en zeker de toekomst. Voor uitwisseling van data is XML zeker de praktijk en de toekomst.

Oh, daar ben ik ook van overtuigd. Zijn we eindelijk af van de mensen die hun eigen variant bedenken op comma-seperated-files (ik heb eens pipe-seperated-files gezien )

We gaan trouwens XML gebruiken voor een help-systeem van een web-app. Lekker handig, hoef je zelf veel lib's en tools niet meer te schrijven, en de klant kan zelf de bestanden beheren (hebben wij meer tijd om te prograprutsen ).

Verder een goed verhaal. Toch eens naar stratego kijken.

[mbravenboer]

Doekman: haha, ik dacht al, transformatie is het stokpaartje van Martin, maar zo'n uitgebreide reactie had ik niet verwacht.

Ik vond het een leuk topic . Hoop dat er leuke reacties komen met veel verschillende meningen .

maar is het nog niet

Javahova is nieuw, er is dus nog niets .

We gaan trouwens XML gebruiken voor een help-systeem van een web-app. Lekker handig, hoef je zelf veel lib's en tools niet meer te schrijven

Das inderdaad precies het voordeel . XML is niet goed, de standaardisatie is goed .

Verder een goed verhaal. Toch eens naar stratego kijken.

Leuk . Stratego is alleen nog niet bepaald toegankelijk te noemen. Documentatie is uitermate sumier omdat het nog volop in ontwikkeling is. Als je het niet uitgelegd krijgt, is het erg lastig te volgen. Ik ben van plan om als de XML capaciteiten van Stratego verbeterd zijn eens een tutorial te gaan schrijven voor 'normale' gebruikers. Ik zal het dan wel ff laten weten. Stratego compileert op dit moment naar C-code die alleen door gcc wordt geaccepteerd (geneste functies). Er zijn echter plannen om naar Java bytecode te gaan compileren. .NET IL is wellicht ook een toekomstige optie.

[razor-x]

Ben ook begonnen met XML en XSL ,
Snap het half
Ik begrijp wel dat het handig kan zijn als je het in verschillende formaaten wilt hebben "wap, html, printable, text-based, pdf "

Maar hoe zet je dan de data in die xml file?
Doe je het zo : "database(mysql ofzo) -> xml bestand maken -> opmaak -> html output" ?
Lijkt mij dan een langzaam?

Enigste probleem waar ik dus niet uit kom, is hoe je de data in z'n xml file zet,
Hoe werkt dat dan op javahova.net?

[Verwijderd]

Op maandag 17 december 2001 23:33 schreef mbravenboer het volgende:

Javahova is nieuw, er is dus nog niets .
[..]

Ah, ik zie het. www.javahova.net is "gewoon" Topicana (het zoveelste php/mysql forum pakket neem ik aan).

Das inderdaad precies het voordeel . XML is niet goed, de standaardisatie is goed .

Inderdaad. Maar comma-seperated-file is gewoon slecht. Het suggereerd dat data-formaat gelijk is aan presentatie-formaat (punt, komma, punt-komma )

Leuk . Stratego is alleen nog niet bepaald toegankelijk te noemen.

Het is voor mij voornamelijk om de ontwikkelingen te volgen. Ik heb bijv. nog nooit een regel java geprogrammeerd, maar door het wat te volgen (en forums lezen) krijg ik een beetje een idee wat (voor een belofte) het inhoudt.

Stratego compileert op dit moment naar C-code die alleen door gcc wordt geaccepteerd (geneste functies).

Geneste functies!!! Doet me denken aan de goede oude Modula-2 tijd. Maare, kun je even uitleggen waarom dat handig is, want dat is mijn modula-2 docent nooit gelukt (maar ik weet wel hoe je het moet compileren, met pen en papier).

[mbravenboer]

Doekman: Ah, ik zie het. www.javahova.net is "gewoon" Topicana (het zoveelste php/mysql forum pakket neem ik aan).

Het forum is een tijdelijke oplossing waar (niet-zichtbaar) over de ontwikkeling wordt gediscussieerd en eventueel al een vraag gesteld kan worden...

Inderdaad. Maar comma-seperated-file is gewoon slecht. Het suggereerd dat data-formaat gelijk is aan presentatie-formaat (punt, komma, punt-komma )

Zeker, maar XML is wel weer ontzettend verbose...

Geneste functies!!! Doet me denken aan de goede oude Modula-2 tijd. Maare, kun je even uitleggen waarom dat handig is, want dat is mijn modula-2 docent nooit gelukt (maar ik weet wel hoe je het moet compileren, met pen en papier).

Hehe, je hebt ook static links gehad Geneste functies zijn alleen handig als ze ook lexical scope bieden: je kunt variabelen uit de functie waarin ze zich bevinden gebruiken (en aanpassen). In (gcc) C hebben ze op zich geen enkel voordeel behalve wat performance winst (voor zover ik weet).

In functionele talen kan je ook geneste functies gebruiken en kan je ook functies opleveren als resultaat of meegeven als parameter. Dit worden hogere orde functies genoemd. Dan wordt het pas echt leuk . Compileren wordt dan een nog grotere uitdaging, want variabelen kunnen dan nog live zijn als een functie returned. Stack-frames moeten dan eventueel op de heap worden gealloceerd . In C kan je ook wel een pointer naar de geneste functie opleveren, je mag hem alleen niet aanroepen .

[Verwijderd]

Op maandag 17 december 2001 23:52 schreef mbravenboer het volgende:

Zeker, maar XML is wel weer ontzettend verbose...

Dat is volgens mij om mensen te ontmoedigen, het als een presentatie-format te zien. (het werkt elkgeval wel )

[mbravenboer]

Doekman: Dat is volgens mij om mensen te ontmoedigen, het als een presentatie-format te zien.

Ik denk dat het ook voor een belangrijk deel te maken heeft met validatie: het opnemen van de tag-naam in de sluit tag is natuurlijk totaal overbodig, tenzij je graag wilt dat de parser snapt wat je eigenlijk bedoelde af te sluiten zodat er betere validatie kan plaats vinden .

Overigens: XSL:FO schijnt pas echt verschrikkelijk te zijn. Als je een redelijk document naar XSL Formatting Objects gaat omzetten schijn je echt enorme lappen tekst te krijgen....

[Verwijderd]

Op maandag 17 december 2001 23:42 schreef razor-x het volgende:
Ben ook begonnen met XML en XSL ,
Snap het half
Ik begrijp wel dat het handig kan zijn als je het in verschillende formaaten wilt hebben "wap, html, printable, text-based, pdf "

Maar hoe zet je dan de data in die xml file?
Doe je het zo : "database(mysql ofzo) -> xml bestand maken -> opmaak -> html output" ?
Lijkt mij dan een langzaam?

Dat is het ook. PHP gaat geen "native" XML ondersteunen (voor zover ik weet). Het lijkt me ook niet handig (daarover ben ik dit topic ook begonnen).

Enigste probleem waar ik dus niet uit kom, is hoe je de data in z'n xml file zet.

Je laat PHP gewoon XML uitspugen, ipv HTML. Dan moet je de HTTP Header "Content-Type: text/xml" toevoegen (die staat normaal op text/html). Hoe dat moet in PHP weet ik niet.

Bovenin je XML staat welke stylesheet (XSLT) die moet gebruiken, en in je browser komt mooie HTML (die maakt de browser dan zelf).

Voordeel: als je de site lelijk vindt, kun je je eigen stylesheet maken

Maar eerlijk gezegd: dat client-side transformeren zie ik niet zitten. Bovenstaand voordeel is vaak een nadeel (ivm advertenties en identity vd site). Server-side transformeren om je site beheersbaar te maken/houden is een beter argument.

En of dat dan moet met XSL? Je hebt (optionele) velden en rijen en die moeten in HTML. Dat kan ook met PHP (je krijgt alleen dollar-tekentjes in je ogen;)). Voordeel van transformaties: ze houden je bij de les: je wordt gedwongen om een bepaalde architectuur te volgen. En dat is goooeeeedddd

[Verwijderd]

Op dinsdag 18 december 2001 00:10 schreef mbravenboer het volgende:

[..]

Ik denk dat het ook voor een belangrijk deel te maken heeft met validatie: het opnemen van de tag-naam in de sluit tag is natuurlijk totaal overbodig, tenzij je graag wilt dat de parser snapt wat je eigenlijk bedoelde af te sluiten zodat er betere validatie kan plaats vinden .

Wel eens een ubb-parser gebouwd? (schijnt te moeten als je op GoT rondhangt ). Je mooie parser komt vol met allerlei uitzonderingen. Het schrijven van een SGML parser is ook een stuk moeilijker dan een XML parser. Simplicity rulez, kennelijk. Hetzelfde zie je met X500 (ingewikkeld) en LDAP (minder ingewikkeld).

Overigens: XSL:FO schijnt pas echt verschrikkelijk te zijn. Als je een redelijk document naar XSL Formatting Objects gaat omzetten schijn je echt enorme lappen tekst te krijgen....

Tsja. Gelukkig bestaat er Content-Transfer-Encoding: gzip

Het belangrijkste van Text-Based protocols/data-structuren is niet dat mensen het kunnen schrijven (dat je HTML uit je hoofd kan intypen wordt steeds minder belangrijk), maar veel meer dat je zaken kunt debuggen, tools ermee overweg kunnen (wel eens de verschillen gezocht in 2 versies van een (binary) word document? niet aan te raden ).

[mbravenboer]

Doekman: Bovenin je XML staat welke stylesheet (XSLT) die moet gebruiken, en in je browser komt mooie HTML (die maakt de browser dan zelf).

Dat vind ik trouwens de grootste misser van het hele systeem: in de XML file staat waarmee deze gestyled moet worden. Krankzinnig! Dit schopt het hele systeem het gebruik van meerdere stylesheets overhoop. Als je de XML dynamisch genereerd is het natuurlijk geen probleem, maar dat is zeker niet altijd het geval. Er had absoluut een ander systeem moeten zijn (en geloof me, dat komt er ook vast wel ) waarin je in een andere file een XML file en een XSL file combineert. Helemaal leuk wordt het als je dan ook nog meerdere stylesheets achter elkaar kunt opgeven , maar dat is in principe geeneens nodig omdat je dat ook weer in een andere vergelijkbare file kunt doen .

[mbravenboer]

Doekman: Wel eens een ubb-parser gebouwd? (schijnt te moeten als je op GoT rondhangt )

Weleens van PostingML gehoord? .

Tsja. Gelukkig bestaat er Content-Transfer-Encoding: gzip

Das waar, maar als je gebruik maakt van de speciale eigenschappen van XML kan je het nog veel beter doen. Er bestaan speciale tools voor XML-compressie (Goh, wat ben ik toch druk geweest ).

maar veel meer dat je zaken kunt debuggen, tools ermee overweg kunnen (wel eens de verschillen gezocht in 2 versies van een (binary) word document? niet aan te raden ).

Das zeker waar . Een speciale toepassing hiervan: .NET gebruikt SOAP in .NET Remoting (het gedistribueerde object systeem van .NET). Je kunt nu in principe gewoon en RMI (het gedistribueerde objectsysteem van Java) implementatie maken die hetzelfde protocol gebruikt . Je kunt dan naadloos een Java-RMI applicatie laten samenwerken met een C#-.NET Remoting applicatie . Hier ben ik al een flinke tijd mee bezig en het begin is er. Door tijdgebrek heb ik nog steeds niet de puntjes op de i gezet .

[Verwijderd]

Op dinsdag 18 december 2001 00:46 schreef mbravenboer het volgende:

[..]

Weleens van PostingML gehoord? .

Nu wel dus

Das waar, maar als je gebruik maakt van de speciale eigenschappen van XML kan je het nog veel beter doen. Er bestaan speciale tools voor XML-compressie (Goh, wat ben ik toch druk geweest ).

Nieuwe GoT wedstrijd: wie quote het meest, en wie/wat wordt het meest gequote? (ideetje wazigh?)

Das zeker waar . Een speciale toepassing hiervan: .NET gebruikt SOAP in .NET Remoting (het gedistribueerde object systeem van .NET).

Ja, da's tof. SOAP gebruiken we al in ons huidige project. Wij doen in win2k en de andere kant doet Linux/Apache. Moet je voorstellen, win2k en Linux praten met elkaar, en niet eens met FTP!!!!!

Verder heeft MS natuurlijk zelf wat bedacht: webservices. Best tof. Een collega heeft net een demootje gemaakt door het interne telefoonboekje (html-interface) beschikbaar te stellen via web-services. Ik moet me er nog even in verdiepen, maar het komt er op neer dat je in je code bij je object wat blokhaak-dingen zet, en dan werkt het via http/soap/enzo. Beetje SOAP extra. Discovery, documentatie vanuit de webservice in je browsertje, dat soort dingen.

[tomato]

Wacht nou eens even, hoe kan ik rustig een reply gaan typen terwijl er steeds weer van zulke lappen tekst bij komen!?!

[Verwijderd]

Op dinsdag 18 december 2001 00:46 schreef mbravenboer het volgende:
Weleens van PostingML gehoord? .

Ah, ik zie dat jij ook onderdeel wilt zijn van de standaard-berg. Wel, hier een uitbreidingsverzoek:

code:

<code language="javascript">
of
<code type="application/x-javascript">

Zodat er aan syntax-highlighting gedaan kan worden. Als demo kun je mijn javascript syntax-highlighting-code gebruiken. Ik dacht zelf aan een UBB uitbreiding: [code=js] en [code=php] ipv die rare [php] tags (te veel eer aan php)

[Verwijderd]

Op dinsdag 18 december 2001 01:05 schreef tomato het volgende:
Wacht nou eens even, hoe kan ik rustig een reply gaan typen terwijl er steeds weer van zulke lappen tekst bij komen!?!

Gewoon 1 browser openhouden: negeer alle posts totdat die van jou gesubmit is

[mbravenboer]

Doekman: Ja, da's tof. SOAP gebruiken we al in ons huidige project. Wij doen in win2k en de andere kant doet Linux/Apache. Moet je voorstellen, win2k en Linux praten met elkaar, en niet eens met FTP!!!!!

Das inderdaad erg tof . Het vervelende van .NET Remoting SOAP is weer dat het erg op .NET gericht is. Je moet via attributen behoorlijk wat aanpassen als je met andere SOAP implementaties (zoals die van Apache en IBM) wilt samenwerken. Het zogenaamde gebruik van standaarden is hier naar mijn mening dan ook 1 groot sprookje. SOAP is namelijk een veel te sumiere standaard . XML-RPC doet het wat dat betreft een stuk beter, maar is ook een stuk beperkter... In mijn implementatie pas ik mij aan de Java kant volledig aan aan .NET SOAP. Daarom hoef je zowel in C#/.NET als in Java/RMI helemaal niets in te stellen. Dat werkt perfect, zolang je maar niet teveel gaat serializeren .

het komt er op neer dat je in je code bij je object wat blokhaak-dingen zet, en dan werkt het via http/soap/enzo. Beetje SOAP extra.

Dat zijn inderdaad de attributen die ik net noemde. In .NET Remoting hoef je die dus in principe niet op te geven, maar dan kan ook alleen .NET (of mijn RMI implementatie ) met je applicatie samenwerken.
Maar goed, dit is eigenlijk een beetje off-topic .

[mbravenboer]

Doekman: Ah, ik zie dat jij ook onderdeel wilt zijn van de standaard-berg.

Ach, het was vooral een projectje om aan te tonen dat een XML-XSL oplossing hiervoor erg makkelijk kan zijn . Ik heb niet de illusie dat iedereen nu opeens PostingML gaat gebruiken. Het dient vooral als voorbeeld en inspiratie .

Wel, hier een uitbreidingsverzoek

Syntax-highlighting zou inderdaad een hele goed uitbreiding zijn, maar helaas stuit je dan op het probleem dat je code moet gaan schrijven in een bepaalde taal. De huidige oplossing is volledig XSL gebaseerd en gebruikt dus totaal geen code in andere talen (behalve voor het toepassen van de transformatie uiteraard). In principe kan je natuurlijk van alles doen als je de DOM server-side in een bepaalde taal gaat manipuleren. Je kan dan in principe welke willekeurige taal ondersteunen...

[mbravenboer]

tomato: Wacht nou eens even, hoe kan ik rustig een reply gaan typen terwijl er steeds weer van zulke lappen tekst bij komen!?!

Sorry . Ik wacht vol spanning .

[Verwijderd]

Op dinsdag 18 december 2001 00:39 schreef mbravenboer het volgende:

[..]

Dat vind ik trouwens de grootste misser van het hele systeem: in de XML file staat waarmee deze gestyled moet worden. Krankzinnig! Dit schopt het hele systeem het gebruik van meerdere stylesheets overhoop.

Correct. Het semantische deel van HTML (en dus ook XML) is het minst begrepen deel, sinds ook non-uni mensen zich met het internet bemoeien. Laten we dat maar als een acceptabel offer beschouwen

In HTML kun je bij de LINK tag aangeven dat je een style-sheet bedoeld hebt voor het scherm of printer (media tag) of dat het een alternatieve stylesheet betreft (rel="alternative stylesheet"). De user-agent had dit moeten oppakken, maar dat was kennelijk niet verplicht in de standaard...

En nu moeten we in ASP een extra print-functie inbouwen, aaarrgghhhh

[Verwijderd]

Op dinsdag 18 december 2001 01:17 schreef mbravenboer het volgende:
Syntax-highlighting zou inderdaad een hele goed uitbreiding zijn

Hmm, javascript highlighting in XSL. Hmm, ik wil eerst de highlighting van regex-literals maken, dan zien we verder.

edit:
Ik bedenk me dat ik hierna eigenlijk een generieke syntax-highlighting wil maken: wil ik wel eens in xsl proberen

[mbravenboer]

Doekman: Hmm, javascript highlighting in XSL.

Dat is denk ik onmogelijk. Je kunt alleen XML content transformeren met XSL... Javascript is dat natuurlijk niet . Het kan eigenlijk alleen in een XSL-extentie worden geimplementeerd of door een aanpassing van de DOM op de server-side. De eerste zijn meestal niet engine-onafhankelijk te krijgen. De tweede oplossing werkt alleen maar in een bepaalde taal. Een leuke oplossing zou zijn om een parser te schrijven die taal x (Javascript, PHP, Java) omzet naar XML content. Die kan je daarna wel een XSL stylen en je hoeft dus alleen nog maar een parser te maken voor de platformen waarop je het systeem wilt gebruiken...

[tomato]

Doekman: Een site als GoT zou bijv. ook wel met transformaties gemaakt kunnen worden. Ik zie echter wat nadelen:
1-Te moeilijk

Een goed doordacht ontwerp van de applicatie wordt steeds meer noodzakelijk (en dat is een 'moeilijk' onderdeel ja, zeker zonder ervaring). Je wordt door het gebruik van dergelijke standaarden vaak gedwongen om reeds in een vroeg stadium over bepaalde dingen na te denken terwijl je je daar anders misschien later druk om zou gaan maken.
Er komen ook wat nieuwe technieken bij, die je als developer natuurlijk tenminste moet begrijpen. En wanneer je alleen werkt zul je natuurlijk zelfs alle technieken moeten beheersen.

Hoewel ik denk dat voor echt grote projecten die niet zo heel erg speelt. Nieuwe technieken komen zowiezo (XML/XSL is niet 'vreemd' wat dat betreft) en er moet gewoon altijd bijgeleerd worden. De complexiteit die XML en XSL met zich meebrengen verdwijnen naar mijn mening geheel in het niet bij grote projecten, omdat daarbinnen toch al veel complexiteit aanwezig was.
Bij kleinere projecten zal het gebruik van XML/XSL een grotere impact op de werkwijze hebben, maar daar is het nut ook vaak wat minder direct aanwezig. Het is natuurlijk ook niet voor niets dat veel 'hobbyisten' op GoT komen vragen wat ze nou eigenlijk aan XML/XSL hebben (ze horen er veel over, maar hoe ik daar nou concreet iets mee moet doen ).

2-Onbekend (PHP werkt toch ook?)

Ben ik niet echt met je eens (echt niet). Onder ontwikkelaaars die een beetje verder kijken dan hun neus lang is en niet te naief zijn (zoals dus eigenlijk ieder ontwikkelaar zou moeten zijn), is XSL volgens mij zeker niet onbekend. Wat mbravenboer al opmerkte (ja ik las stiekem vooruit ), veel gebruik van XML/XSL blijft min of meer onopgemerkt voor de buitenwereld.
Bij enkele nuttige mogelijkheden van XML is het nogal triviaal duidelijk dat dit ook voor de buitenwereld zichtbaar is (denk bijv aan een XML Tracker van T.net), maar verder is het natuurlijk helemaal niet nodig dat jij iets merkt van welke techniek achter een applicatie zit (liever niet zelfs).

3-Performance (XSL schiet tot nu toe niet echt op)

Zelf weinig aan benchmarking gedaan en ik weet ook niet precies waar je nu direct op doelt, maar dat idee heb ik niet. Je doelt waarschijnlijk op de extra transformatie die zowiezo nodig is? Zonder XML/XSL te gebruiken is die transformatie (al dan niet geheel zichtbaar) ook aanwezig (scheiding van data en opmaak is geen nieuw concept) en het is natuurlijk iets dat erg gevoelig is voor optimalisatie met behulp van caching of een variant daarvan.
Wanneer we het over websites hebben kunnen we nog vooruit kijken naar client-side XSL processing. Hoewel dat erg leuk is verwacht ik niet dat ik er zeer snel op ga vertrouwen. Maar buiten websites kunnen transformaties natuurlijk heel goed op een (vorm van) client toegepast worden.

Zijn er ook andere mensen real-world met dit bezig?

Niet IRL aan het ontwikkelen aan een real-world applicatie nee. Ik geef wel enige ondersteuning aan een collega die zich in een nieuw project aan het storten is (waar ik mooie mogelijkheden zag liggen ).
Zelf heb ik er niet genoeg tijd voor. Veel kleine dingen proberen en ontdekken, maar er is nog te veel waar ik in de echte praktijk geen ervaring mee heb

Ok, straks misschien nog reacties op de reacties, maar ik zag al dat veel dingen die ik wilde gaan zeggen in een volgende reactie al gezegd werden. Ook even kijken of het bier al wat wil zakken (dan schrijf ik minder onzin ).

[razor-x]

Op dinsdag 18 december 2001 01:18 schreef mbravenboer het volgende:

[..]

Sorry . Ik wacht vol spanning .

/ot
mbravenboer + tomato + xml = lange reacties

[mbravenboer]

tomato schreef een goed stuk

Leuk stukje . Helaas ben ik het overal zo ontzettend mee eens dat ik niet echt de behoefte heb om ergens op in te gaan. Ik zal toch 1 kleine dingetje pakken .

Wanneer we het over websites hebben kunnen we nog vooruit kijken naar client-side XSL processing. Hoewel dat erg leuk is verwacht ik niet dat ik er zeer snel op ga vertrouwen.

Grappig dat we het er eigenlijk wel unaniem over eens zijn dat dit voorlopig niets wordt .

Onlangs zat ik trouwens nog aan een 2 andere groot nadelen van client-side transformaties te denken. Je kunt XSL vaak ook goed inzetten om te 'filteren'. Simpele voorbeelden hiervan zijn bijvoorbeeld het laten zijn van een beperkt aantal reacties. Een andere serieuzer voorbeeld het filteren van content naar aanleiding van rechten van een bezoeker. In het eerste geval heeft client-side transformatie (filtering) natuurlijk enorme gevolgen voor de snelheid en heft vaak het hele voordeel van het filteren op. In het tweede geval is client-side transformatie natuurlijk helemaal belachelijk.

Dit wordt nog veel belangrijker als je bronnen gaat combineren: stel je hebt een XML view met gegevens van alle GoT leden. Je zou dan bij een posting alleen een verwijzing op kunnen nemen naar een element van die XML view. Via een XSLT stylesheet kan je dat lekker combineren (alhoewel dit misschien een wat slecht voorbeeld is). Als je dit echter client-side gedaan wordt, moet er veel te veel gedownload worden....

Ook even kijken of het bier al wat wil zakken (dan schrijf ik minder onzin ).

Foei . Overigens vond ik je verhaal niet zo onzinnig, dus ben benieuwd hoe kwalitatief de verdere reacties wel niet worden .

[tomato]

robin0223:
Het voordeel van xml & xsl is dat je bvb je database (sql server in ieder geval) puur xml kan laten uitpoepen en dit snel omzetten.

Ik zie dat niet als een voordeel van XML/XSL (dan altijd nog als een voordeel van de dbm software) en zeker niet als het voordeel. Een relationele database is (het woord zegt het al) relationeel. Dit is XML niet, ik begrijp dus in wezen niet zo goed wat je er precies aan hebt om de data op een SQL query terug te krijgen in XML formaat. Deze XML zal namelijk net zo plat zijn als een conventionele recordset, terwijl XML nou net zo mooi hierarchisch is (kan zijn dus). Vrijwel nooit zul je je data aan willen bieden in het formaat dat je uit SQL Server (in XML) terugkrijgt (net zo min als hoe je dat altijd al terugkrijgt).
Overigens hebben nog lang niet alle dbm's deze functionaliteit (daar gaat je portabiliteit) en welke het wel hebben, hebben het op verschillende manieren en niet altijd standaard (daar gaat je portabiliteit die je toch al niet had ).

Door gelijk xml uit je database te zuigen heb je tijdswinst.

Dat zal slechts in enkele gevallen zo zijn denk ik. Wanneer iets als een XML recordset echt interessant kan worden zal er een alternatief voor SQL moeten komen ('platter' dan SQL kan niet) en zal het aanspreken van een database functioneel en intern ingrijpend moeten veranderen. Ik weet eerlijk gezegd niet uit mijn hoofd of er stappen in deze richting gezet worden en hoever deze eventueel zijn (kon er laatst nog niet veel over vinden).

Op de Microsoft DevDays werd trouwens verteld dat de komende versie van MS SQL Server compleet op xml gebaseerd zal worden en dus nog beter te combineren zal zijn met xml.

XML doet het natuurlijk goed in toespraken op DevDays
Ik hecht persoonlijk niet zo veel waarde aan dergelijke uitspraken. Ik zie liever funcionele voorbeelden van een (aankomende) feature implementatie.

robin0223: xml idd DE techniek als je het over webservices hebt...

In huidige implementaties van webservices zou je dat zo kunnen zien ja. Maar XML is absoluut niet waar het om draait bij het idee van webservices. Overal waar je 'XML' leest zou morgen net zo goed 'tomato' kunnen staan (nouja, bij wijze van een fictief voorbeeld natuurlijk )

mbravenboer: Een XML+XSL gebaseerd forum zou inderdaad fantastisch zijn omdat je dan ook direct te data kan benaderen.

Met het idee van verschillende views op een dataset komen we al direct op het punt dat door jou verderop 'de grootste misser van het hele systeem' genoemd wordt. Het is inderdaad ook mij volkomen onduidelijk van het nut om een stylesheet te binden aan een dataset (andersom zou een stuk functioneler en logischer zijn). Er zijn natuurlijk altijd kromme omwegen, maar IMHO had dit toch wat mooier gekund.

Of transformatie een blijvertje is?

Deze vraag zou ik eigenlijk het liefste indirect beantwoorden: is XML een blijvertje? Jazeker: het aanbieden van data in de vorm van XML is nu al vaak de praktijk en zeker de toekomst. Voor uitwisseling van data is XML zeker de praktijk en de toekomst.

Ik sta hier toch wat kritischer tegenover. XML zal zeker erg veel gebruikt gaan worden en zal voorlopig niet verdwijnen. Maar voor een groot deel komt dit IMHO door de (intussen toch wel goed gelukte) introductie en standaardisatie van XML. Daardoor zijn er al enorm veel tools voor XML (denk alleen al aan de enorme waarde van het bestaan van XSL voor XML) en is het ook totaal niet nuttig nu iets vergelijkbaars te gebruiken, maar net niet hetzelfde is.
Toch is XML zeker niet de perfectie zelve. Op de eerste plaats moet je je er natuurlijk van bewust zijn dat XML (net als alles) niet de oplossing kan zijn voor alles. Er zijn gewoon (enorm veel) situaties denkbaar waar XML niet nuttig is en daar zit een remming in het gebruik van XML.
Op de tweede plaats is XML ook niet de perfecte oplossing voor de meeste problemen waar het wel een aardige of goede oplossing voor is. En wat niet perfect is verdwijnt (hoewel dit lang kan duren en veel complicaties met zich mee kan brengen, denk bijvoorbeeld aan een HTTP protocol, toch zal ook dit uiteindelijk verdwijnen). Een duidelijk aspect van XML is dat het begrijpbaar is voor een mens. Wanneer je een XML document ziet kun je dit 'lezen'. Dat is natuurlijk leuk en makkelijk enzo, maar is dit nou ook echt nodig? Ik denk dat die noodzaak steeds verder zal verdwijnen. En wanneer die noodzaak niet aanwezig is, is een belangrijk aspect van XML overbodig (juist een aspect waar een hoop negatieve kanten aan zitten!). Verder noemde mbravenboer al iets als het afsluiten van een element waar de naam van het element genoemd moet worden. Dat is natuurlijk al helemaal iets wat in feite overbodig is en nog niet eens noodzakelijk om een formaat leesbaar voor mensen te houden.
Er zullen daarnaast ook nog nadelen die nu misschien nog niet duidelijk zijn of erg klein lijken naar voren komen in de toekomst. Waarom zouden 'fouten' of onvolkomenheden aanwezig zijn in veel protocollen? Tijdens ontwerp zullen ze niet voorspeld zijn en dus komen ze pas naar voren na grootschalig gebruik.

Vaak zal je data echter willen combineren of van structuur wijzigen. Hiervoor is XSLT de perfect oplossing.

Alles transformeert

Ik denk wel dat het belangrijkste voordeel van XSLT ook gelijk het grootste nadeel zal worden. XSLT is relatief eigenlijk een vrij eenvoudige taal. De opzet van XSLT is vrij duidelijk te begrijpen. De kracht van XSLT is naar mijn mening echter vooral te danken aan XPath en de gedachte structurele recursie. XSLT zelfs stelt verder niet zoveel voor. Complexere transformaties zijn vaak niet uit te drukken of worden zeer complex. De grootste beperking is naar mijn mening dat output, output is. Je kan nooit op een deelresultaat van je transformatie nog een keer wat transformaties toepassen.

Iedereen is natuurlijk vrij om XML te transformeren met iets anders dan XSL . Aan een standaard als XSL zit je veel minder direct vast in je applicatie dan aan iets als XML. Het lijkt me dan ook duidelijk dat er in de toekomst alternatieven komen, XSL drastische veranderingen zal ondergaan, of een combinatie van beiden.

Daarom zie ik eigenlijk ook een toekomst voor de betere transformatie-talen. Het model van XSLT zal niet aangepast worden en dus zal het nooit voldoen voor alle complexe transformaties.

( Ik lees meestal van boven naar beneden. Ik weet het, het is vaag, maar dat vind ik prettig )
Even serieus off-topic: Ik ben van mening dat het een stuk interessanter is om gewoon op volgorde reacties te geven dan eerst alles te lezen vervolgens te reageren. Nadeel is weer wel dat er af en toe wat dubbel gezegd zal worden

mbravenboer: Ik denk trouwens dat veel sites al niet zichtbaar XSL gebruiken. Je kan op dit moment uiteraard niet vertrouwen op client-side transformatie (en het is de vraag of je dat ooit zult kunnen doen).

Inderdaad. Ik vraag me trouwens ook af of je ooit echt zult kunnen vertrouwen op client-side transformatie door een third-party. Wanneer je zelf verantwoordelijk bent voor en controle hebt over de client is het natuurlijk een prachtig concept, maar in de huidige situatie mbt internetsites (met clients van Microsoft, Mozilla, Netscape, name them...) kijk ik er anders tegenaan.

Orphix: mbravenboer, je zegt dat je een betere toekomst ziet voor andere transformatie talen. Nu vraag ik mij af in hoeverre XSLT niet voldoet waar andere talen dat wel kunnen.

Goed punt.

Ik geloof dat er namelijk veel meer gebruikers/programmeurs zijn die XML data naar HTML willen transformeren dan programmeurs die de XML output van MS SQL server recursief en omgedraaid alfabetisch gesorteerd op id nummer naar Oracle XML output willen transformeren. (dit is een fictief onderwerp he )

Tsja, persoonlijk vind ik XSL niet op alle punten even geniaal, wat dat betreft zie ik dus wel ruimte voor andere XML transformatietalen. Maar of er ook direct op puur functioneel gebied behoefte aan is? Jij en ik hebben die behoefte nu waarschijnlijk niet, maar anderen ongetwijfeld wel.

Dus: is het praktisch gezien logisch/nuttig om veel tijd en moeite te stoppen in een moeilijkere transformatie taal?

Zeker wel, maar niet voor jou, behalve als je je blik wat wilt verruimen.

PlayR: Ja, wij zijn met www.javahova.net hiermee bezig. Het word al met al een leuk systeempje, en jullie kunnen ook een keer een uitgebreide uitleg krijgen van je hoe je leuk een site met xml en xslt op kan zetten..

* tomato is erg benieuwd maar heeft er alle vertrouwen in

edit: maar daar zijn we nog eventjes niet aan toe

Jammer, ik zou erg graag een keer een overzicht zien van wat jullie allemaal gedaan hebben met mogelijke knelpunten en oplossingen (uiteraard als de site 'af' is)

mbravenboer: 'definitieviteit' (vaag woord, zal vast niet bestaan )

Sorry, geen zin om het voor je op te zoeken dit keer

LOL, Hehe . Wat ik bedoelde: het is absoluut niet ingewikkeld om een schijnbaar vrij eenvoudige transformatie te verzinnen die enorm lastig of onmogelijk in XSLT te beschrijven is. Hierbij gaat het vooral om het verzamelen van gegevens en het opslaan van deze gegevens voor een verder punt in de transformatie. Ook worden stylesheets snel onnodig complex omdat je niet componenten kunt werken: output = output. Als output niet zo definitief was, zou je je transformatie beter kunnen verdelen in een aantal componenten.

Zowiezo vind ik XSL niet geschikt voor ingewikkelde transformaties. Een en ander wordt snel zeer onduidelijk. Voor echt grote applicaties lijkt me XSL ook een volstrekt onbruikbare transformatietaal, omdat met het gebruik van XML transformaties een enorm belangrijk onderdeel kunnen worden. Naar mijn mening moet dit allemaal duidelijk, snel en makkelijk kunnen, maw, ik heb het idee dat uiteindelijk een hogere transformatietaal noodzakelijk zal zijn.

Mwah, het zou denk ik wat kortzichtig zijn om XSLT te accepteren als het best haalbare. Stratego zal zeker niet de transformatie-taal worden, maar het is een interessant onderzoek naar wat er mogelijk moet zijn in een transformatie-taal.

Onderzoek leidt tot resultaat (of dat is tenminste meestal de bedoeling )

Doekman: Oh, daar ben ik ook van overtuigd. Zijn we eindelijk af van de mensen die hun eigen variant bedenken op comma-seperated-files (ik heb eens pipe-seperated-files gezien )

In dataopslag zie ik eigenlijk niet een uitgesproken mooi gebruik van XML. Voor opslag van sommige data wel, maar naar mijn mening blijft XML toch vooral geschikt om data aan te bieden en uit te wisselen, niet om data op te slaan. XML is hierarchisch, niet relationeel. Het brengt te veel overhead met zich mee om langdurig data op te slaan.

Doekman: Inderdaad. Maar comma-seperated-file is gewoon slecht. Het suggereerd dat data-formaat gelijk is aan presentatie-formaat (punt, komma, punt-komma )

Nee, ben ik niet met je eens. Wanneer er niet meerdere views op de data nodig zijn hoeft er niets mis te zijn met comma-seperated files. Je moet XML niet als heilige datadrager zien. Stel je voor dat een ASM coder voortaan een array als XML document in het geheugen implementeerde

Het is voor mij voornamelijk om de ontwikkelingen te volgen. Ik heb bijv. nog nooit een regel java geprogrammeerd, maar door het wat te volgen (en forums lezen) krijg ik een beetje een idee wat (voor een belofte) het inhoudt.

Goed zo
* tomato vindt het ook erg belangrijk (en leuk) om van alles wat op te pikken en je blik zo veel mogelijk te verruimen!

mbravenboer: Das zeker waar . Een speciale toepassing hiervan: .NET gebruikt SOAP in .NET Remoting (het gedistribueerde object systeem van .NET). Je kunt nu in principe gewoon en RMI (het gedistribueerde objectsysteem van Java) implementatie maken die hetzelfde protocol gebruikt . Je kunt dan naadloos een Java-RMI applicatie laten samenwerken met een C#-.NET Remoting applicatie . Hier ben ik al een flinke tijd mee bezig en het begin is er. Door tijdgebrek heb ik nog steeds niet de puntjes op de i gezet .

In XML-RPC gaat dit nog verder (of liever gezegd in SOAP zijn ze daar weer iets van afgeweken). Het mooie is dat iedereen XML-RPC kan praten en verstaan (potentieel natuurlijk ). Voor SOAP geldt dit ook voor een groot deel.

Doekman: Ja, da's tof. SOAP gebruiken we al in ons huidige project. Wij doen in win2k en de andere kant doet Linux/Apache. Moet je voorstellen, win2k en Linux praten met elkaar, en niet eens met FTP!!!!!

Je moet niet vergeten dat SOAP in feite niets anders is dan een bijeenraping van het aloude HTTP, XML en wat van Maggie (of was het Microsoft?). Maar natuurlijk is het een erg mooie techniek, te meer omdat je je er in de praktijk eigenlijk helemaal niet druk om hoeft te maken (HTTP is niets nieuws voor je, XML ook niet).

Doekman: Gewoon 1 browser openhouden: negeer alle posts totdat die van jou gesubmit is

's Nachts werkt beter

mbravenboer: SOAP is namelijk een veel te sumiere standaard . XML-RPC doet het wat dat betreft een stuk beter, maar is ook een stuk beperkter...

Inderdaad. XML-RPC is ook veel gemakkelijker qua ontwerp. Je begrijpt hoe het werkt wanneer je het concept ervan kent. Het is inderdaad ook een stuk beperkter, dat is een van de nadelen (en ten opzichte van SOAP ook eigenlijk het nadeel dat ik kan verzinnen) van XML-RPC en is natuurlijk een gevolg van de simpliciteit.

mbravenboer: Ach, het was vooral een projectje om aan te tonen dat een XML-XSL oplossing hiervoor erg makkelijk kan zijn . Ik heb niet de illusie dat iedereen nu opeens PostingML gaat gebruiken. Het dient vooral als voorbeeld en inspiratie .

Ik neem aan dat PostingML op Javahova gebruikt zal gaan worden? Denk er dan wel aan dat je vanaf het moment dat je het gebruikt een standaard introduceert. Als het concept anderen ook aanspreekt (mij wel iig) zullen ze volgen, maar het zou mooi zijn als ze dit dan volgens dezelfde standaard zouden doen. Wanneer jij de eerste bent die iets soortgelijks gebruikt denk ik niet dat het een illusie hoeft te zijn om een standaard neer te zetten. Als je er goed over nagedacht hebt, wat zou dan een reden voor iemand kunnen zijn om daar van af te wijken? En al met al is standaardisatie natuurlijk erg belangrijk

razor-x:/ot
mbravenboer + tomato + xml = lange reacties

Tsja, wat is lang?

mbravenboer:Leuk stukje . Helaas ben ik het overal zo ontzettend mee eens dat ik niet echt de behoefte heb om ergens op in te gaan. Ik zal toch 1 kleine dingetje pakken .

Dankje

<topic>Client-side XSL processing</topic>

Grappig dat we het er eigenlijk wel unaniem over eens zijn dat dit voorlopig niets wordt .

Onlangs zat ik trouwens nog aan een 2 andere groot nadelen van client-side transformaties te denken. Je kunt XSL vaak ook goed inzetten om te 'filteren'. Simpele voorbeelden hiervan zijn bijvoorbeeld het laten zijn van een beperkt aantal reacties. Een andere serieuzer voorbeeld het filteren van content naar aanleiding van rechten van een bezoeker. In het eerste geval heeft client-side transformatie (filtering) natuurlijk enorme gevolgen voor de snelheid en heft vaak het hele voordeel van het filteren op. In het tweede geval is client-side transformatie natuurlijk helemaal belachelijk.

Ja, wanneer je ivm rechten XSL gaat toepassen valt client-side natuurlijk direct af. Vind ik zowiezo nogal tricky om hier XSL voor te gebruiken, in een goed applicatie model hoeft dit volgens mij ook niet voor te komen. Ik denk hooguit aan [delete] knopjes die wel of niet zichtbaar zijn adhv iemands rechten, dat is iets wat prima met XSL kan natuurlijk.

Verder noem je nog wel een belangrijk punt. Ik zou dit eigenlijk nog iets verder door willen trekken als direct nadeel van stylesheets zoals die bij XSL werken (passief in plaats van actief zou ik het eigenlijk willen noemen). Neem als voorbeeld de frontpage van T.net in XML formaat (komt er vast ooit nog aan ). Wellicht wordt er een jaar lang een stylesheet gebruikt waarin ergens aan de bezoeker getoond welke 10 leden zich als laatst aangemeld hebben (zodat zij zich ook even vereerd voelen ). Deze informatie zal logischerwijs in het XML document opgenomen worden. Maar het volgende jaar heeft Femme het ontwerp van de FP wat aangepast en is er geen ruimte meer voor deze informatie. Toch wordt er bij iedere aanroep van de FP nog een query gedaan naar de laatste 10 leden. Wanneer een stylesheet 'actief' zou zijn, zou de applicatie geven waar om gevraagd wordt en niet genoodzaakt zijn altijd al het mogelijke te geven.

Dit wordt nog veel belangrijker als je bronnen gaat combineren: stel je hebt een XML view met gegevens van alle GoT leden. Je zou dan bij een posting alleen een verwijzing op kunnen nemen naar een element van die XML view. Via een XSLT stylesheet kan je dat lekker combineren (alhoewel dit misschien een wat slecht voorbeeld is). Als je dit echter client-side gedaan wordt, moet er veel te veel gedownload worden....

Inderdaad. Een voordeel van XML is hierdoor ook niet oneindig door te voeren. Het is natuurlijk ideaal om voor verschillende views op dezelfde data (of juist delen daarvan) maar XML document te hoeven genereren, maar zoals je al aangeeft zul je altijd in een achterliggende laag van je applicatie rekening moeten houden met welke views er op de welke data gewenst zijn.

Foei . Overigens vond ik je verhaal niet zo onzinnig, dus ben benieuwd hoe kwalitatief de verdere reacties wel niet worden .

Je zal ondertussen wel naar bed zijn, heb even gewacht tot het postingspeelkwartier hier over was

[mbravenboer]

Allemachtig, dit is vast een van de langste posts ooit . Ik ga hem lezen .

[tomato]

mbravenboer: Allemachtig, dit is vast een van de langste posts ooit . Ik ga hem lezen .

In feite staat er nog niet eens iets nieuws in

[mbravenboer]

tomato: Een relationele database is (het woord zegt het al) relationeel. Dit is XML niet, ik begrijp dus in wezen niet zo goed wat je er precies aan hebt om de data op een SQL query terug te krijgen in XML formaat.

Op zich is dat wel zo, maar relationele databases zijn natuurlijk ook de manier voor data-opslag. XML-databases, semi-structured databases en object-georienteerde databases zijn hiermee vergeleken complete dwergen. Databases die serieus over XML support hebben nagedacht bieden soms vrij geavanceerde mogelijkheden om relationele modellen te mappen naar XML. Het beste voorbeeld waar ik van gehoord heb is op dit punt IBM met DB/2. Deze waarschijnlijk nog steeds min of 'lineaire' XML, kan daarna met behulp van XSLT makkelijk naar een hierarchische structuur worden getransformeerd. Het grote voordeel hiervan is, dat je de transformatie van relationele data naar hierarchische data kunt uitvoeren in een min of meer declaratieve taal: XSLT.

Je kunt het sterk vergelijken met het vertalen van XML naar objecten, waar we het pas over hadden. Je kunt die vertaling op heel veel manieren doen: (1) hard-coden in een imperatieve taal, waarbij je de XML file inleest en omzet naar objecten of (2) XSLT gebruiken om de XML file om te zetten naar 'object-XML' die direct kan worden ingelezen. De vertaling met behulp van methode (2) is waarschijnlijk veel aantrekkelijker dan methode (1). Voor het vertalen van relationele data naar xml data geldt dit denk ik ook...

Dat zal slechts in enkele gevallen zo zijn denk ik. Wanneer iets als een XML recordset echt interessant kan worden zal er een alternatief voor SQL moeten komen ('platter' dan SQL kan niet) en zal het aanspreken van een database functioneel en intern ingrijpend moeten veranderen. Ik weet eerlijk gezegd niet uit mijn hoofd of er stappen in deze richting gezet worden en hoever deze eventueel zijn

Ik neem aan dat je vooral doelt op XQuery? Ik heb niet veel gezien van XQuery, maar wat ik gezien heb vond ik vrij briljant . Helaas zal het vrij lastig te implementeren zijn omdat het bepaald een eenvoudig taaltje is, maar als databases dit gaan ondersteunen kunnen we in onze handen gaan wrijven .

In huidige implementaties van webservices zou je dat zo kunnen zien ja. Maar XML is absoluut niet waar het om draait bij het idee van webservices. Overal waar je 'XML' leest zou morgen net zo goed 'tomato' kunnen staan (nouja, bij wijze van een fictief voorbeeld natuurlijk )

Hehe, dat zou je wel willen he? .

Het is inderdaad ook mij volkomen onduidelijk van het nut om een stylesheet te binden aan een dataset (andersom zou een stuk functioneler en logischer zijn). Er zijn natuurlijk altijd kromme omwegen, maar IMHO had dit toch wat mooier gekund.

Blij te horen dat meer mensen het achtelijke van deze vage constructie inzien . Ik hoop dat het doordringt in de gelederen van het W3C .

[ * mbravenboer zei dat XML de toekomst is voor data aanlevering en uitwisseling ]
Ik sta hier toch wat kritischer tegenover. XML zal zeker erg veel gebruikt gaan worden en zal voorlopig niet verdwijnen. Maar voor een groot deel komt dit IMHO door de (intussen toch wel goed gelukte) introductie en standaardisatie van XML.

De invoering van XML is in feite de meest geslaagde standaardisering. Ik kan mij geen enkele standaard herrinneren, waar iedereen zich ook daadwerkelijk volledig aan ging houden. Eigenlijk is dat best wel verbazingwekkend, maar uiteraard ook weer fantastisch.

Toch is XML zeker niet de perfectie zelve. Op de eerste plaats moet je je er natuurlijk van bewust zijn dat XML (net als alles) niet de oplossing kan zijn voor alles. Er zijn gewoon (enorm veel) situaties denkbaar waar XML niet nuttig is en daar zit een remming in het gebruik van XML.

Nou ja, hier ben ik het niet helemaal mee eens... Ik denk dat je sowieso onderscheid moet maken tussen situaties waarin je een universeel data-type wilt gebruiken en waar je dit niet wilt of nodig hebt. Als je dit niet wilt is de toepassing van XML of wat voor andere syntaxtische standaard voor data-uitwisseling natuurlijk sowieso niet logisch. Als je dit wel wilt, zie ik maar weinig nadelen van XML. De grote kracht van de huidige standaardisering is volgens mij dat er zo'n enorme tool-support is voor XML, dat het vrijwel altijd onzinnig zal zijn om de nadelen van XML in jouw situatie op te gaan lossen met een eigen syntax. Uiteindelijk zal je altijd blijven proberen om de standaard-tools te gebruiken.

Ook moet er natuurlijk goed onderscheid worden gemaakt tussen syntax en model. XML is tenslotte slechts een syntax. Je kunt gerust tools ontwikkelen die intern helemaal niets direct met de syntax van XML te maken hebben. Het meest toepasselijke voorbeeld is Stratego met ATermen: ATermen zijn buitengewoon interessant. ATermen zijn in feite volkomen superieur aan XML. De ATerm library abstraheert namelijk van de gebruikte syntax en biedt in feite alleen een run-time object-structuur aan. Deze structuur is buitengewoon geavanceerd: efficient en geheugengebruik + de maximale deling van subtermen: als knopen aan elkaar gelijk zijn, worden ze maar op 1 plaats opgeslagen in het geheugen. De ATerm lib biedt verschillende opslag-vormen: een uitermate compacte binaire vorm en een leesbare vorm die iets compacter is dan XML. In de binaire vorm blijft de maximale sharing behouden! Deze vorm is dus uitermate geschikt voor uitwisseling. Daarnaast is de tekst-vorm zeer geschikt voor debugging.

Zoals al gezegd, gebruikt Stratego dus ATermen. Nu is het interessant om in Stratego ook XML files te kunnen transformeren. Het enige wat nu nodig is, is een output-vorm van ATermen in XML.

Ok, waar wil ik heen? Simpel: in Stratego of andere ATerm toepassingen zijn de nadelen van XML niet relevant vanwege de interne representatie. XML is slechts een mogelijke syntax waaruit deze interne representatie kan worden afgeleid.

Dit heft denk ik een belangrijk argument tegen XML op. Nadelen zijn intern vaak niet relevant.

denk bijvoorbeeld aan een HTTP protocol, toch zal ook dit uiteindelijk verdwijnen

Weet je wat mij nu leuk lijkt? Een XML gebaseerde HTTP opvolger .

Nee, dat bedoel ik heel serieus. HTTP is in feite een draak van een protocol met een belachelijke syntax. XML zou een perfect syntax zijn voor een HTTP opvolger: snelle standaard tools om request te parsen, mogelijkheid voor binaire attachments zoals in SOAP en op alle platformen te gebruiken. Heerlijk toch? .

Verder noemde mbravenboer al iets als het afsluiten van een element waar de naam van het element genoemd moet worden. Dat is natuurlijk al helemaal iets wat in feite overbodig is en nog niet eens noodzakelijk om een formaat leesbaar voor mensen te houden.

Maar wel een zeer goed middel om de correctheid van een XML file nog beter te kunnen beoordelen....

Overigens is het zeker niet ontdenkbaar dat er ooit een alternatieve, binaire syntax zal komen voor XML die vergelijkbaar is met de binaire syntax van ATermen...

Alles transformeert

Uiteraard .

Ik lees meestal van boven naar beneden. Ik weet het, het is vaag, maar dat vind ik prettig )

Zit op zich wel wat in, maar kan ook reacties vna "huh dat zei ik toch!" uitlokken . De gedachtengang is zo wel beter te volgen .

maw, ik heb het idee dat uiteindelijk een hogere transformatietaal noodzakelijk zal zijn.

Stratego for president!

Stel je voor dat een ASM coder voortaan een array als XML document in het geheugen implementeerde

En wat is daar mis mee Ik wilde in mijn Tiger-compiler eigenlijk SOAP gaan gebruiken voor method-calls en ook XML voor stack-frames .

Inderdaad. XML-RPC is ook veel gemakkelijker qua ontwerp. Je begrijpt hoe het werkt wanneer je het concept ervan kent. Het is inderdaad ook een stuk beperkter, dat is een van de nadelen (en ten opzichte van SOAP ook eigenlijk het nadeel dat ik kan verzinnen) van XML-RPC en is natuurlijk een gevolg van de simpliciteit.

Idd, XML-RPC is natuurlijk ongeschikt voor het doorgeven remote-object references of serializatie van complexe objecten. Waarschijnlijk is dit ook gelijk een voordeel van XML-RPC omdat dit niet te standaardiseren is. Het voordeel van SOAP is dat dit ook niet gestandaardiseerd is, het nadeel is dat je de implementatie aan de andere kant in niet-simplistische gevallen vaak moet kennen.

Ik neem aan dat PostingML op Javahova gebruikt zal gaan worden?

Waarschijnlijk wel, maar misschien ook een alternatieve ubb pre-processor ( ) .

Wanneer jij de eerste bent die iets soortgelijks gebruikt denk ik niet dat het een illusie hoeft te zijn om een standaard neer te zetten.

Hum ja, dat is op zich ook wel weer zo... Ik vind PostingML goed uitgedacht. Ik kan mij niet voorstellen dat gebruikers constructies echt fundamenteel anders zouden willen hebben. Uitbreidingen zijn wel weer logisch: voor GoT zou je bijvoorbeeld typisch een forum, topic of profile tag kunnen nemen.

Toch wordt er bij iedere aanroep van de FP nog een query gedaan naar de laatste 10 leden. Wanneer een stylesheet 'actief' zou zijn, zou de applicatie geven waar om gevraagd wordt en niet genoodzaakt zijn altijd al het mogelijke te geven.

Dat is inderdaad waar, maar het kan ook opgelost worden door je site verstandig op te zetten. Ik ben een groot voorstander van een gelaagd systeem waarbij je niet direct uit je data-bron (meestal een relationele database) XML-views gaat genereren die eigenlijk verschillende types data bevatten. Liever zou ik zien dat er bovenop de database een verzameling XML bronnen worden gedefinieerd die bepaalde gegevens representeren (data-XML). Daarboven kan dan een laag worden gelegd die deze XML-bronnen combineert tot nieuwe XML vormen: view-XML. Deze vormen kunnen daarna getransformeerd worden naar een gewenste output (XHTML, WML, PDF, whatever). Als je nu een goed caching systeem toepast kan je ervoor zorgen dat naar aanleiding van een request alleen de benodigde data-XML wordt gebruikt en deze data-XML alleen wordt ververst als dit ook echt noodzakelijk is. Volgens mij is dit de allerbeste opzet voor het aanbieden van data en views op deze data. Het probleem wat jij noemt is hiermee ook opgelost...

Je zal ondertussen wel naar bed zijn, heb even gewacht tot het postingspeelkwartier hier over was

Nu zal jij wel naar bed zijn? . Je houdt me wel van m'n werk zeg .

[tomato]

mbravenboer: Databases die serieus over XML support hebben nagedacht bieden soms vrij geavanceerde mogelijkheden om relationele modellen te mappen naar XML. Het beste voorbeeld waar ik van gehoord heb is op dit punt IBM met DB/2. Deze waarschijnlijk nog steeds min of 'lineaire' XML, kan daarna met behulp van XSLT makkelijk naar een hierarchische structuur worden getransformeerd.

Ik heb je dit eerder horen noemen (DB/2 XML features), heb er toen volgens mij ook ooit eens wat naar gezocht, maar eigenlijk weet ik er vrijwel niets van. Punt blijft voor mij dat je niet via SQL kunt gaan.

Ik neem aan dat je vooral doelt op XQuery? Ik heb niet veel gezien van XQuery, maar wat ik gezien heb vond ik vrij briljant . Helaas zal het vrij lastig te implementeren zijn omdat het bepaald een eenvoudig taaltje is, maar als databases dit gaan ondersteunen kunnen we in onze handen gaan wrijven .

Ik weet nog niet veel van XQuery, maar op iets dergelijks doelde ik denk ik inderdaad. Eens even wat meer informatie opzoeken...

Dit lijkt wel een aardige introductie en hier wordt ook zeer beknopt door XQuery gelopen.
Hier een XQuery Demo, waar je zelf je queries kunt runnen op voorbeeld data (deze is trouwens ook leuk)

Maar XQuery kun je alleen gebruiken op XML, dus om hier wat mee te kunnen doen in een relationele database zul je hier eerst een XML view van moeten hebben. Toch
Het ziet er inderdaad allemaal erg mooi uit (dat ingewikkeld valt ook wel weer mee als je je er even in verdiept denk ik). Maar moeten we XQuery niet meer zijn als grote broer van XSL? Hoe je nou in een rdbm iets aan XQuery zou kunnen hebben ontgaat me eigenlijk een beetje...

<topic>Stylesheet link in XML bron</topic>

Blij te horen dat meer mensen het achtelijke van deze vage constructie inzien . Ik hoop dat het doordringt in de gelederen van het W3C .

Eigenlijk viel me dit al op toen ik 10 minuten van XSL gehoord had. Toen dacht ik eigenlijk dat ik het wel verkeerd zou begrijpen ofzo, maar eigenlijk vind ik het nu nog steeds vreemd (en jij gelukkig ook ).

De invoering van XML is in feite de meest geslaagde standaardisering. Ik kan mij geen enkele standaard herrinneren, waar iedereen zich ook daadwerkelijk volledig aan ging houden. Eigenlijk is dat best wel verbazingwekkend, maar uiteraard ook weer fantastisch.

Ik kan ook geen enkele reden verzinnen waarom je XML zou gebruiken en af zou wijken van de standaard (wat kleine puntjes mbt character encodings etc daargelaten).

Ook moet er natuurlijk goed onderscheid worden gemaakt tussen syntax en model. XML is tenslotte slechts een syntax.

Ja daar heb je gelijk in. Je schrijft een mooi verhaal over ATermen wat me zeer aanspreekt, maar feit is dat XML slechts 1 syntax kent. Stratego zal toch de twee output-vormen moeten kunnen transformeren naar de interne datavorm (en andersom)? Wanneer er een alternatieve XML syntax zou komen, hoe triviaal dit ook is, kunnen huidige tools er toch niet mee overweg?

Zoals al gezegd, gebruikt Stratego dus ATermen. Nu is het interessant om in Stratego ook XML files te kunnen transformeren. Het enige wat nu nodig is, is een output-vorm van ATermen in XML.

Naar wat ik uit je verhaal kan op maken is dit dus vrij triviaal en vereist het alleen aanpassingen in de ATermen lib van Stratego?

HTTP is in feite een draak van een protocol met een belachelijke syntax. XML zou een perfect syntax zijn voor een HTTP opvolger: snelle standaard tools om request te parsen, mogelijkheid voor binaire attachments zoals in SOAP en op alle platformen te gebruiken. Heerlijk toch? .

Geweldig, maar zie jij de revolutie al beginnen?

<topic>Element naam in XML sluittag</topic>

Maar wel een zeer goed middel om de correctheid van een XML file nog beter te kunnen beoordelen....

Alleen in incorrecte gevallen. En overbodig dus...

Overigens is het zeker niet ontdenkbaar dat er ooit een alternatieve, binaire syntax zal komen voor XML die vergelijkbaar is met de binaire syntax van ATermen...

Kijk, daar zat ik nou heel je reactie al op te wachten . Voor mij zou dit veel nadelen van XML uit de weg ruimen, maar hoe denkbaar is het dat die er zal komen? Uiteraard kan iedereen er binnen 2 minuten een definieren, maar wat hebben we er aan? Bestaande tools zullen er niet mee overweg kunnen, ook al is het gewoon XML met een andere syntax.

En wat is daar mis mee Ik wilde in mijn Tiger-compiler eigenlijk SOAP gaan gebruiken voor method-calls en ook XML voor stack-frames .

Lolbroek

Idd, XML-RPC is natuurlijk ongeschikt voor het doorgeven remote-object references of serializatie van complexe objecten. Waarschijnlijk is dit ook gelijk een voordeel van XML-RPC omdat dit niet te standaardiseren is. Het voordeel van SOAP is dat dit ook niet gestandaardiseerd is, het nadeel is dat je de implementatie aan de andere kant in niet-simplistische gevallen vaak moet kennen.

Precies. Zelf ben ik eigenlijk niet zo weg van SOAP. Het mooie van XML-RPC is dat je absoluut geen kennis hoeft te hebben van de implementatie aan de andere kant, terwijl dit met SOAP in de praktijk eigenlijk niet meer werkt.

Waarschijnlijk wel, maar misschien ook een alternatieve ubb pre-processor ( ) .

* tomato votes for PostingML

Zeer interessant verhaal over een applicatiemodel (storage, data-XML, view-XML, output)

Dat is inderdaad een mooie oplossing. Maar de performance van dit model staat of valt met goede caching. En volgens mij is het vrij ingewikkeld in zo'n systeem goede caching toe te passen, zeker als verschillende onderdelen van je applicatie (lager dan view-XML laag) verspreid zijn. Neem in ieder geval een functioneel ontwerper in dienst met kennis van zaken

Nu zal jij wel naar bed zijn? . Je houdt me wel van m'n werk zeg .

Dat dacht je

[mbravenboer]

Jeetje, die tomato houdt het aardig vol .

Maar XQuery kun je alleen gebruiken op XML, dus om hier wat mee te kunnen doen in een relationele database zul je hier eerst een XML view van moeten hebben. Toch

Yep, das waar. Maar die kan je natuurlijk definieren onafhankelijk van het daadwerkelijke opslag-formaat. Voor een relationele database is het wel mogelijk, maar ietwat ongelukkig.

Het ziet er inderdaad allemaal erg mooi uit (dat ingewikkeld valt ook wel weer mee als je je er even in verdiept denk ik).

Nou ja, het is ook niet zozeer ingewikkeld om te gebruiken, maar wel om volledig te ondersteunen in een database systeem. Het is nogal een krachtig systeem wat ongeveer relationeel compleet is in het kwadraat ( om ff wat onzinnigs te zeggen ). Implementaties zullen denk ik niet meevallen. Maar wellicht dat de mapping naar de echte vorm van data-opslag nog het lastigst is.

Maar moeten we XQuery niet meer zijn als grote broer van XSL?

Mwah, dat denk ik toch niet. In het boek "Data on the Web" wordt XSL ook behandelt als query taal, maar dat raakt denk ik kant nog wal. XSLT blijft een transformatie-taal... De benaming stylesheet vind ik al uitermate ongelukkig, als het nu ook nog een query-taal wordt is de pret helemaal compleet . Het grootste probleem van XSLT als query-taal is denk ik de opzet vast XSLT: je transformeert een XML bron naar een andere willekeurige vorm. Als je dat gaat gebruiken als query taal op een grote database wordt het uitermate ingewikkeld om een query-plan op te stellen en te bepalen wat er ingelezen moet worden. Uiteraard wil je niet heel database even in een XML file stoppen . Ik denk dat je XQuery echt moet zien als query taal over XML-data, die niet percee ook fysiek XML-data hoeft te zien. Dat je het in de query-taal als semi-structured data kunt gebruiken is het grootste voordeel.

Hoe je nou in een rdbm iets aan XQuery zou kunnen hebben ontgaat me eigenlijk een beetje...

Inderdaad is een mapping hier wel vrij noodzakelijk. Overigens kan je XML ook wel generiek in een database opslaan, maar dit wordt vrij inefficient. Als je deze stuff echt interessant vind, kan ik je het boek "Data on the Web" sterk aanbevelen. Het is op sommige punten een matig boek, maar op veel punten (speciaal deze) ook erg interessant.

Ja daar heb je gelijk in. Je schrijft een mooi verhaal over ATermen wat me zeer aanspreekt, maar feit is dat XML slechts 1 syntax kent. Stratego zal toch de twee output-vormen moeten kunnen transformeren naar de interne datavorm (en andersom)? Wanneer er een alternatieve XML syntax zou komen, hoe triviaal dit ook is, kunnen huidige tools er toch niet mee overweg?

Als er een andere syntax zou komen voor XML is de interne representatie nog steeds hetzelfde. Er zullen maar weinig tools zijn die direct op de syntax van XML werken (behalve XML parsers). Applicaties die gebruik maken van SAX of DOM parsers kunnen de nieuwe syntax gewoon aan. Heel veel tools gebruiken SAX of desnoods DOM en dus hoeft een nieuwe syntax niet echt een probleem te zijn.

Naar wat ik uit je verhaal kan op maken is dit dus vrij triviaal en vereist het alleen aanpassingen in de ATermen lib van Stratego?

Helaas is dat ook weer niet zo... ATermen kennen geen mixed-content. Daar zul je dus een goede oplossing voor moeten vinden. Ook heeft een ATerm een vast aantal kinderen, iets wat bij XML ook niet zo is. ATermen hebben daarentegen weer lijsten.... Allereerst moet je dus zorgen dat er een goede mapping is van een XML file naar ATermen. Dit kan in feite alleen gebeuren met behulp van een DTD of een XML Schema. Ook werkt Stratego met data-type definities (vergelijkbaar met OO-klassen, FP-data-typen, structs, records, DTD en dergelijke). Deze moeten gegenereerd worden uit het schema. Uiteraard zouden we ook met een generiek data-type kunnen werken (een DOM met Elementen, Attributen en dergelijke) maar dat is erg onaantrekkelijk. Uiteindelijk is het de bedoeling dat uit een XML-Schema een Stratego signature gegeneerd kan worden. XHTML is hiervan natuurlijk direct een belangrijke kandidaat...

[XML-HTTP]Geweldig, maar zie jij de revolutie al beginnen?

Hehe, het zou me wel een schok zijn .

Kijk, daar zat ik nou heel je reactie al op te wachten . Voor mij zou dit veel nadelen van XML uit de weg ruimen, maar hoe denkbaar is het dat die er zal komen?

Dat hangt denk ik vooral van de snelheid af waarmee internet zich ontwikkeld.... .NET is natuurlijk zeer druk met data-uitwisseling via XML. Als de performance daarvan gaat tegenvallen zou je weleens een beweging kunnen krijgen die om een binaire XML syntax roept. Zoals ik net probeerde duidelijke te maken hoeft dat dus denk ik niet zoveel gevolgen te hebben voor applicaties.

* tomato votes for PostingML

Tja, * mbravenboer ook, maar ik heb niet alles voor het zeggen .

Dat is inderdaad een mooie oplossing. Maar de performance van dit model staat of valt met goede caching.

Als je nog eens tijd hebt, moet je eens naar Apache's Cocoon kijken . Ik heb er nog nooit echt mee gewerkt, maar het klinkt erg goed.

[tomato]

mbravenboer: Nou ja, het is ook niet zozeer ingewikkeld om te gebruiken, maar wel om volledig te ondersteunen in een database systeem. Het is nogal een krachtig systeem wat ongeveer relationeel compleet is in het kwadraat ( om ff wat onzinnigs te zeggen ). Implementaties zullen denk ik niet meevallen. Maar wellicht dat de mapping naar de echte vorm van data-opslag nog het lastigst is.

Met implementaties heb ik toch niets te maken . Maar inderdaad wel leuk, om een mooie standaard te verzinnen en te publiceren en er dan vanuit te gaan dat derden die wel even gaan implementeren. Toch denk ik dat dat wel goed komt hoor

Heb je trouwens gezien dat XQuery geen vaste syntax heeft, of in ieder geval 3 syntaxen? De standaard query syntax is trouwens gelukkig geen XML.

<topic>XQuery als super XSL</topic>

Mwah, dat denk ik toch niet.

Ok, in je uitleg kan ik mij wel vinden.

Ik denk dat je XQuery echt moet zien als query taal over XML-data, die niet percee ook fysiek XML-data hoeft te zien.

Ja, dat is een goede opmerking (dat laatste, tenminste ik neem aan dat je met 'zien' 'zijn' bedoelde?). Dan blijft in sommige gevallen inderdaad het lastige punt om een XML view van de data te maken.

Overigens kan je XML ook wel generiek in een database opslaan, maar dit wordt vrij inefficient.

Goh wat is er toch allemaal al niet geprobeerd als alternatief voor relationele databases

Als je deze stuff echt interessant vind, kan ik je het boek "Data on the Web" sterk aanbevelen. Het is op sommige punten een matig boek, maar op veel punten (speciaal deze) ook erg interessant.

Zal eens kijken, maar je weet het... _tijd

Applicaties die gebruik maken van SAX of DOM parsers kunnen de nieuwe syntax gewoon aan. Heel veel tools gebruiken SAX of desnoods DOM en dus hoeft een nieuwe syntax niet echt een probleem te zijn.

Eigenlijk doelde ik ook op de XML parsers zelf, die toch erg veel gebruikt worden en vervangen zullen moeten worden. Maar je hebt wel gelijk, voorbij dat niveau heb je er natuurlijk niets mee te maken.

ATermen - XML

Leuk dat je er af en toe wat meer informatie over geeft. Je houdt ons zo af en toe op de hoogte ok?

Als je nog eens tijd hebt, moet je eens naar Apache's Cocoon kijken . Ik heb er nog nooit echt mee gewerkt, maar het klinkt erg goed.

* tomato gaat er nu naar kijken...

[D2k]

<enigszins ot>
ik heb net dit topic eens doorgelezen en er zijn bij mij 2 vragen gerezen:
• slapen jullie nooit ?
• waarom altijd dit soort discussies als ik al lig te pitten ligt het aan mij??

</enigszins ot>
Maar tis bijzonder interessant om te lezen iig
Ik wil ook in januari na de stage met XML gaan beginnen om eens te kijken of ik er wat mee kan.

[tomato]

D2k: ik heb net dit topic eens doorgelezen en er zijn bij mij 2 vragen gerezen:

Ben blij dat het verder allemaal kristalhelder voor je is

<li> slapen jullie nooit ?

</li>
Jawel, maar te weinig en op ietwat 'afwijkende' tijden

<li> waarom altijd dit soort discussies als ik al lig te pitten ligt het aan mij??

</li>
Ach, waarom gaat D2k altijd pitten wanneer er dit soort discussies beginnen?

Ik wil ook in januari na de stage met XML gaan beginnen om eens te kijken of ik er wat mee kan.

Tuurlijk kun je er iets mee, succes alvast
_{ik zie je vragen wel komen}

[D2k]

tomato: Ben blij dat het verder allemaal kristalhelder voor je is

wat wil je jullie maken er zoveel woorden aan vuil

• Jawel, maar te weinig en op ietwat 'afwijkende' tijden

ahh dat is het

• Ach, waarom gaat D2k altijd pitten wanneer er dit soort discussies beginnen?

Ik was zelfs allang weg voor deze discussie begon

Tuurlijk kun je er iets mee, succes alvast
_{ik zie je vragen wel komen}

En ik weet jullie te vinden bij vragen

[Verwijderd]

* doekman huilt, boehoe, ik wil ook weer student zijn en niet op tijd naar bed hoeven

Toch valt het mee. Werk is ook leuk, alleen op sommige momenten bekruipt me de weemoed... Nog even een paar korte reacties, nadat ik dit hele verhaal geprint heb, en het tijdens koffie-pauzes doorgelezen heb (alle bits op een hoop, wat een lap text):

XML-HTTP: Bestaat natuurlijk al een beetje: WebDAV, regelt oa locken van resources, een machine-readable collection-listing (dir) en het setten van (user-def.) properties. Voorbeeldje van xml gebruik: een http-response geeft maar 1 status. Met DAV kun je een multi-status terugkrijgen (en ja, dat is geimplementeerd met xml). Maar het zou inderdaad beter kunnen.

Binary XML: Lijkt me geen goed idee. Jullie onderschatten de kracht van plain/text. Het probleem: er moeten mensen mee werken, de computers zijn het probleem niet.

[side-topic]
object-oriented-database: Het lijkt erop dat het alleen handig is voor directories (LDAP, ActiveDirectory, NDS etc.). En dan gaat het alleen nog maar om de toegang. Intern wordt vaak een relationele engine gebruikt (MS SiteServer gebruikt MS SQL Server).

En toch vermoed ik dat zoiets handig zou zijn. Neem groupware zoals Lotus Notes. Stel eens een open-source groupware pakket voor. Hoe zou je al die gegevens willen opslaan en delen?
[/side-topic]

CSV: tomato: Op zich is CSV niet slecht, maar in gebruik blijkt het dat bijv. Outlook een CSV uitpoept met waarden uit de Region (dus op mijn NL systeempje krijg ik een punt-komma seperated list, en daar kan een ander programma weer niets mee).
Als iedereen gewoon als seperator een komma gebruikt, een punt als decimaal-scheidingsteken en er ook een duidelijke afspraak is over quotes, dan zou het perfect zijn. Lekker simpel, weinig overhead, toch human-readable.

LDIF (LDAP Directory Interchange Format) vind ik ook wel handig. Hier is tenminste een goed gespecificeerde RFC voor. En dat maniertje van vCard vind ik ook wel geinig.

XML heilig? Natuurlijk niet, maar zeker handig.

XML-RPC: Is mij onbekend, maar ik geloof jullie op je woord dat het "beter" is. Alleen, waarom zou iedereen XML-RPC moeten gaan leren, terwijl bijna iedereen al SOAP gebruikt. ICT is best wel conservative, you know? (maar ik ga natuurlijk wel eens kijken wat het betekend )

XML uitspugende rel-db's: als je snel even wat pagina's moet maken, met server-side XSLT is het vast handig, maar verder

mbravenboer: De invoering van XML is in feite de meest geslaagde standaardisering. Ik kan mij geen enkele standaard herrinneren, waar iedereen zich ook daadwerkelijk volledig aan ging houden. Eigenlijk is dat best wel verbazingwekkend, maar uiteraard ook weer fantastisch.

Zijn hypes toch ergens goed voor

mbravenboerNee, dat bedoel ik heel serieus. HTTP is in feite een draak van een protocol met een belachelijke syntax. XML zou een perfect syntax zijn voor een HTTP opvolger: snelle standaard tools om request te parsen, mogelijkheid voor binaire attachments zoals in SOAP en op alle platformen te gebruiken. Heerlijk toch?

Het probleem is dat het "compatible" moest blijven, of zo. Kennelijk toch belangrijker dan jullie hopen ...

samenvatting: Transformaties kunnen handig zijn, en informatica is vet leuk.

[Rense Klinkenberg]

Damn zeg, kijk je eens een dagje niet op GoT, komen net de toffe topics voorbij wandelen

En als je zo'n topic eindelijk hebt doorgelezen, is al het commentaar dat je wou geven eigenlijk ook al gegeven (scheelt mij natuurlijk wel een typewerk )

[mbravenboer]

tomato: Heb je trouwens gezien dat XQuery geen vaste syntax heeft, of in ieder geval 3 syntaxen? De standaard query syntax is trouwens gelukkig geen XML.

Inderdaad, het is een tijdje geleden dat ik ermee bezig ben geweest, maar als ik het goed heb waren het vooral meerdere views (syntaxen) op hetzelfde systeem, waarbij je niet direct in de meest expliciete syntax hoeft te werken. Gelukkig hebben ze door dat je programmeurs niet lastig moet vallen met jouw gemakzucht: als je altijd in een abstracte syntax gaat programmeren is parsen eenvoudig, maar programmeren prut .

dat laatste, tenminste ik neem aan dat je met 'zien' 'zijn' bedoelde?

Ja inderdaad, te snel getikt .

Leuk dat je er af en toe wat meer informatie over geeft. Je houdt ons zo af en toe op de hoogte ok?

Uiteraard . In dit geval gaat het niet echt om informatie over een taal die in de toekomst 'het' moet gaan worden, maar toch is het denk ik wel interessante stuff . Een transformatie-taal waarin je zelfs een compiler kunt schrijven is natuurlijk niet gering .

D2k :slapen jullie nooit ?

Daar ben ik overheen geevolueerd .

waarom altijd dit soort discussies als ik al lig te pitten ligt het aan mij??

Omdat ik overdag niet online kan zijn .

[tomato]

Doekman: * doekman huilt, boehoe, ik wil ook weer student zijn en niet op tijd naar bed hoeven

Student zijn is ook niet alles hoor

Binary XML: Lijkt me geen goed idee. Jullie onderschatten de kracht van plain/text. Het probleem: er moeten mensen mee werken, de computers zijn het probleem niet.

Ben ik niet helemaal met je eens. Er zijn erg veel gevallen waarin er geen enkele gebruiker (ook geen ontwikkelaar) in aanraking zou moeten komen met de XML (dus ook niet met de syntax daarvan). Wat deze syntax dan is is niet echt relevant wat dat betreft en hoeft er dus ook niet vastgehouden te worden aan een of ander mooi human-readable formaat.

XML-RPC: Is mij onbekend, maar ik geloof jullie op je woord dat het "beter" is. Alleen, waarom zou iedereen XML-RPC moeten gaan leren, terwijl bijna iedereen al SOAP gebruikt. ICT is best wel conservative, you know? (maar ik ga natuurlijk wel eens kijken wat het betekend )

Nouja, 'beter'... Kijk anders deze thread even door.

XML uitspugende rel-db's: als je snel even wat pagina's moet maken, met server-side XSLT is het vast handig, maar verder

Dan nog zie ik het nut er niet echt van in (op de manier zoals SQL Server het nu aanbiedt bedoel ik).

Het probleem is dat het "compatible" moest blijven, of zo. Kennelijk toch belangrijker dan jullie hopen ...

Ja, dat is op veel gebieden natuurlijk een 'probleem'.

mbravenboer: Inderdaad, het is een tijdje geleden dat ik ermee bezig ben geweest, maar als ik het goed heb waren het vooral meerdere views (syntaxen) op hetzelfde systeem, waarbij je niet direct in de meest expliciete syntax hoeft te werken. Gelukkig hebben ze door dat je programmeurs niet lastig moet vallen met jouw gemakzucht: als je altijd in een abstracte syntax gaat programmeren is parsen eenvoudig, maar programmeren prut .

Helemaal mee eens

Daar ben ik overheen geevolueerd .

Kun je daar misschien ook eens een tutorial over schrijven?

[mbravenboer]

tomato: Kun je daar misschien ook eens een tutorial over schrijven?

Zal eens kijken wat ik kan doen .

Arien: En ja, ik zit acher Windows *gasp*
Arien: Ik gebruik verder ASP... ik houd niet van regexen, maar gebruik XPath, gebruik IE en Opera en geen Mozilla en wat nog meer....?
tomato: hmmm jammer

Als ik het goed begrijp plaats Arien XPath hier in dezelfde hoek als Opera, IE en MS Windows. Wat is er mis met XPath? .

[tomato]

mbravenboer: Als ik het goed begrijp plaats Arien XPath hier in dezelfde hoek als Opera, IE en MS Windows. Wat is er mis met XPath? .

Niets
Was meer bedoeld als lokkertje

Ik betrapte Arien er op dat hij achter Windows zat (naja, hij betrapte zichzelf) en toen kwamen er ineens allemaal heel enge dingen uit zijn mond

Overigens was Arien het niet helemaal eens met onze opvatting over de 'misplaatste' XSL refenentie in een XML bron. Verder vond hij het vooral een enorm verhaal

[mbravenboer]

tomato: Ik betrapte Arien er op dat hij achter Windows zat (naja, hij betrapte zichzelf) en toen kwamen er ineens allemaal heel enge dingen uit zijn mond

Yukkie, dat krijg je kennelijk als je moet gaan werken .

Overigens was Arien het niet helemaal eens met onze opvatting over de 'misplaatste' XSL refenentie in een XML bron.

Hoezo? Ben wel benieuwd waarom hij het daar dan niet mee eens was...

Het komt er op neer dat je een in de XML-bron aangeeft hoe je deze wilt stylen. Dat wil je toch niet

Verder vond hij het vooral een enorm verhaal

[tomato]

mbravenboer: Hoezo? Ben wel benieuwd waarom hij het daar dan niet mee eens was...

Het komt er op neer dat je een in de XML-bron aangeeft hoe je deze wilt stylen. Dat wil je toch niet

Ik heb de chat nog liggen... staat niet zo netjes om hier direct neer te planten, dus ik zet het deel wel even op WebDevX (weet je nog hoe je daar moet komen?).

Misschien wel even een kleine samenvatting straks hier neer zetten anders staat dat ook weer zo lullig he

[edit]
Gemaild als het goed is

[mbravenboer]

tomato: ik zet het deel wel even op WebDevX (weet je nog hoe je daar moet komen?).

Nee, kan je het (de inlog gegevens voor WebDevX dus ) misschien ff mailen? De gegevens staan op m'n oude compu .

Misschien wel even een kleine samenvatting straks hier neer zetten anders staat dat ook weer zo lullig he

Hum ja .

[Mafioso]

WHAAA word er soms een wedstrijdje gehouden wie het langste verhaal kan schrijven ?

Anyway ik snap r niet veel van wat hier allemaal word gezegt .. nouja mijn tijd komt nog wel (zullen we maar zeggen)