[XML] RDDL: innovatief, interessant en handig!

[mbravenboer]

Ik bij Roger L. Costello van http://www.xfront.com (die werkelijke grandioze tutorials schrijft over XML Schema, XSLT en XPath) een nieuwe tutorial tegen over RDDL. Ik dacht: verrek, een acroniem die mij is ontgaan! Ik ging dus even uitzoeken wat dat was en was blij verrast .

Wat is RDDL?

RDDL is werkelijk een uitermate goed idee naar mijn mening. Ik zal kort uitleggen wat het is en even wat makkelijke links plaatsen naar bronnen waar je meer kunt vinden .

De Resource Directory Description Language (RDDL dus, spreek uit: riddle) is een XML gebaseerd taal om bronnen rond een XML namespace te beschrijven. Volgens het W3C moet een XML Namespace een URI zijn. Een URI hoeft echter niet percee een document op het web te zijn en daarom is het in feite vaak een URN ipv een URL. Het is dus niet gedefenieerd waarnaar een namespace moet verwijzen. Dit kan niets zijn, maar ook bijvoorbeeld een DTD of een XML Schema.

RDDL biedt hiervoor een zeer interessante oplossing. Met behulp van RDDL kan je op de locatie van de namespace allerlei resources beschrijven die met de namespace te maken hebben. Je kunt hierbij denken aan een XML Schema, Document Type Definition, XSL stylesheets voor verschillende toepassingen, Cascading Stylesheets enzovoorts. Tussen deze bronnen door kan je ook in XHTML een beschrijving geven van de bronnen en de namespace.

Waarom is dit handig?

Stel dat een browser of een andere applicatie een XML document binnen krijgt met een onbekende namespace... In principe kan een browser hier niets mee: hij moet weten hoe deze zaak moet worden weergegeven. De browser weet echter de namespace van de elementen. Als achter deze namespace een RDDL document zit, kan deze worden opgehaald en kan de browser bijvoorbeeld een XSLT bron proberen te vinden die transformeert naar XHTML.

Dat klinkt cool, dat wil ik gebruiken!

Dan nu het probleem: het is geen W3C standaard. Het meeste rumoer rond RDDL stamt uit jan/feb/maart 2001. Daarna is het vrij stil geweest rond RDDL en support voor RDDL is matig. W3C heeft ooit achter XML Schema namespace een RDDL beschrijving gestopt, maar ondertussen is dat het XML Schema van XML Schema zelf. Ook kon ik nergens iets vinden over plannen voor RDDL support in bijvoorbeeld Mozilla of IE6.

RDDL is erg eenvoudig, dus support voor RDDL is niet lastig. Ik vind het dan ook jammer dat RDDL kennelijk een beetje is stil gevallen.

Wat wil je nu eigenlijk van me?

Zoals je merkt heb ik de ontwikkeling van RDDL niet echt gevolgd, dus mijn vraag: wie heeft dit wel gevolgd en kan misschien iets vertellen over de redenen waarom de support niet echt op gang is gekomen? Weet iemand iets over plannen voor RDDL support in Mozilla? Ik kon namelijk helemaal niets vinden op Bugzilla. Zou het zinvol zijn om RDDL een schop te geven en een bug te posten op Bugzilla?

Bronnen

RDDL website
RDDL tutorial op xfront.com
RDDL artikel op xml.com
RDDL artikel op O'Reilly News

[ErectionJackson]

Ik heb hier een hele tijd geleden inderdaad wat over gelezen, maar ik wilde toen even afwachten hoe de ontwikkeling zou gaan van RDDL voordat ik eraan wilde beginnen. Straks heb je iets moois gemaakt en veranderen ze de hele specificatie, zodat het nutteloos wordt (in het ergste geval ). Maar inderdaad, het werd verdomd stil rondom RDDL.

Ik heb even op ASPToday gezocht, maar ik kon er niks op vinden helaas, terwijl zij meestal wel goede tutorials hebben over vrijwel elk onderwerp. Ik denk dat je het ergste moet vrezen.

[Verwijderd]

[n00b] Wat is een namespace?

[mbravenboer]

Agijsbro: [n00b] Wat is een namespace?

Hum.... In XML kan je uiteraard je eigen element-namen verzinnen. Je wilt soms ook graag elementen uit verschillende standaarden in 1 document gebruiken. Om dan duidelijk te maken bij welke standaard een element hoort zijn namespaces geintroduceerd. Je moet in XML in principe op een element aangeven bij welke namespace deze hoort.

HTML heeft bijvoorbeeld een eigen namespace, die je ook altijd zou moeten gebruiken als je met XHTML werkt. Verder heeft eigenlijk iedere W3C standaard een namespace: XSLT, XSL Formatting Objects, RDF, SVG, SOAP, XLink (ga nu niet vragen wat dat stuk voor stuk allemaal is ).

Als je zelf een nieuwe XML 'standaard' opstelt kan je zelf ook een namespace introduceren.

Zie de W3C Recommendation als je er echt alles over wilt weten:
http://www.w3.org/TR/1999/REC-xml-names-19990114/

[Verwijderd]

Op woensdag 23 januari 2002 06:09 schreef mbravenboer het volgende:
Hum.... In XML kan je uiteraard je eigen element-namen verzinnen. Je wilt soms ook graag elementen uit verschillende standaarden in 1 document gebruiken. Om dan duidelijk te maken bij welke standaard een element hoort zijn namespaces geintroduceerd. Je moet in XML in principe op een element aangeven bij welke namespace deze hoort.

Een soort doctype voor elementen?

Edit: op verzoek van mbravenboer wat ingekort..

[mbravenboer]

_{kan je misschien een beetje selectief quoten? Dit neemt zo onnodig veel ruimte in beslag... dank}
.

Agijsbro: Een soort doctype voor elementen?

Nee, een document type verwijst naar bepaald schema waaraan een document moet voldoen. Hier zitten dus structuur vereisten van een XML document in.

Een namespace is meer een extra onderdeel van de tag-naam. Hierdoor zijn tag-namen weer uniek.

De tag-naam 'b' uit XHTML kan daardoor bijvoorbeeld ook voorkomen in een andere XML formaat, bijvoorbeeld PostingML. Je kunt nu XHTML content en PostingML content mixen terwijl de applicatie die de XML gebruikt toch weet dat de 'b' van XHTML een andere 'b' is dan de 'b' van PostingML . Je zou ook kunnen kiezen voor de tagnamen html-b en postingml-b, maar dat schiet weer niet zo op .

Je kunt het een beetje vergelijken met achternamen: als je Martin zoekt, kan je veel verschillende mensen treffen. Als je Martin Bravenboer gaat zoeken kom je waarschijnlijk iets eerder bij mij terecht . Als je echter in een groep bent en je hebt mij nodig, roep je gewoon Martin. Zo zit het ook precies bij XML namespaces .

[mbravenboer]

ErectionJackson: Ik denk dat je het ergste moet vrezen.

Erg jammer... Het aardige van RDDL vind ik dat een browser of applicatie bijvoorbeeld over totaal onbekende XML structuren gegevens kan verkrijgen. Het is heel logisch om dat achter de namespace te stoppen .

Ik vind het eigenlijk onverklaarbaar dat dit niet serieus is aangeslagen (althans: veel projecten gebruiken het wel) of dat er geen vergelijkbaar project bij het W3C loopt...

[Verwijderd]

Op woensdag 23 januari 2002 06:32 schreef mbravenboer het volgende:
_{kan je misschien een beetje selectief quoten? Dit neemt zo onnodig veel ruimte in beslag... dank}
.

Haha.. Is goed.. Was idd een beetje gemakzucht..

Bedankt voor de uitleg, ik snap 't.
Ook waardeer ik dat je dit soort dingen post. _{no suck up shit, gewoon oprecht dankbaar}

[mbravenboer]

Agijsbro: Was idd een beetje gemakzucht..

Geefnie .

ik snap 't.

Mooi . Graag gedaan

[ErectionJackson]

Op woensdag 23 januari 2002 06:41 schreef mbravenboer het volgende:

[..]

Erg jammer... Het aardige van RDDL vind ik dat een browser of applicatie bijvoorbeeld over totaal onbekende XML structuren gegevens kan verkrijgen. Het is heel logisch om dat achter de namespace te stoppen .

Ik vind het eigenlijk onverklaarbaar dat dit niet serieus is aangeslagen (althans: veel projecten gebruiken het wel) of dat er geen vergelijkbaar project bij het W3C loopt...

Inderdaad. Misschien moeten we een petitie starten om t toch aan te laten slaan

[mbravenboer]

ErectionJackson: Misschien moeten we een petitie starten om t toch aan te laten slaan

Nog geeneens zo'n gek idee . In ieder geval zou Mozilla support RDDL al aardig in leven houden . Misschien dat er dus eens een bug-report voor RDDL moet worden gemaakt...

[mbravenboer]

Hier een document uit September 2001 van een vrij hoge pief bij het W3C die RDDL bespreekt:

http://www.w3.org/People/cmsmcq/2001/nsrddl.html

[Orphix]

Wat is dan het verschil tussen een schema+xsl meegeven aan het xml bestand?

[mbravenboer]

Orphix: Wat is dan het verschil tussen een schema+xsl meegeven aan het xml bestand?

Als je een XSL stylesheet aangeeft in een XML document via een processing instruction, geef je eigenlijk aan dat hij hiermee percee getransformeerd moet worden. Via RDDL werkt het heel anders: er is een bepaald type document. Dit type document biedt je aan aan een applicatie/browser. Deze kan nu via de RDDL specificatie gaan uitzoeken welke stylesheet hij zou kunnen gebruiken om het XML document weer te geven of om een andere reden om te zetten naar een vorm die hij wel begrijpt.

Voor XML-Schema is dat wat minder logisch, maar je zou kunnen denken aan het aanbieden van verschillende schema-vormen. Bovendien is het natuurlijk prettig als je niet elk document hoeft te vervuilen met (in principe) dubbelop informatie: schema instantie en namespace....

[Verwijderd]

Men moet de koppeling: XML - XSLT - Browser eens loslaten. XML en XSLT hebben geen moer met een webbrowser te maken. Dat sommigen het gebruiken voor het genereren van (X)HTML is leuk, maar slechts bijzaak, het schept alleen maar verwarring en foutief besef wat de kracht van XML nu eigenlijk is.

Namespaces zijn leuk, maar maken XML docs dermate complex dat je je afvraagt of het het doel niet voorbijschiet.

[Nielsz]

Op woensdag 23 januari 2002 18:23 schreef Otis het volgende:
Men moet de koppeling: XML - XSLT - Browser eens loslaten. XML en XSLT hebben geen moer met een webbrowser te maken. Dat sommigen het gebruiken voor het genereren van (X)HTML is leuk, maar slechts bijzaak, het schept alleen maar verwarring en foutief besef wat de kracht van XML nu eigenlijk is.

Martinnnn! I'm confused
Ik heb toch echt geleerd dat XML beschrijft wat je data is, en dat XSLT zegt hoe hij het weer moet geven.
Wat is het dan wel

[mbravenboer]

Otis: Men moet de koppeling: XML - XSLT - Browser eens loslaten.

Ik zei ook nadrukkelijk dat een applicatie of browser de RDDL specificatie zou kunnen gebruiken. Ik zie RDDL niet alleen als interessant voor in een browser, maar zie daar zeker wel een interessante toepassing.

Wellicht nog een aardige toepassing met betrekking tot data-binding: je zou in een RDDL specificatie Java klassen beschikbaar kunnen stellen die je kunt gebruiken om het XML document in te lezen... Een applicatie kan deze downloaden en gebruiken via interfaces.

XML en XSLT hebben geen moer met een webbrowser te maken.

Je kunt XML en XSLT op ontzettend veel manieren gebruiken en het vind ook zijn toepassing in een webbrowser. Ik vind dit dus wel wat sterk uitgedrukt.

Dat sommigen het gebruiken voor het genereren van (X)HTML is leuk, maar slechts bijzaak, het schept alleen maar verwarring en foutief besef wat de kracht van XML nu eigenlijk is.

XSLT wordt helaas vooral gebruikt voor het transformeren naar XHTML dus dat dit vaak in samenwerking met een browser wordt genoemd verbaast mij eigenlijk absoluut niet. Zelf gebruik ik het echter vooral in andere situaties, waarin er geen relatie is met XHTML of een browser. Je kunt XSLT bijvoorbeeld heel goed gebruiken als je XML data moet inlezen in een applicatie.

Als jij vind dat mensen (ik?) een foutief besef hebben van de kracht van XML, doe je er goed aan om jouw visie dan ook even uit te leggen denk ik .

De kracht van XML komt naar mijn mening voort uit een heleboel punten en je vindt deze kracht terug in enorm veel toepassingen, waaronder ook het aanleveren van pure data, waaruit je een presentatie in taal x kunt transformeren. Presentatie kan je hier in de meeste ruime zin van het woord lezen...

Namespaces zijn leuk, maar maken XML docs dermate complex dat je je afvraagt of het het doel niet voorbijschiet.

Namespaces zijn imho noodzakelijk als meerdere standaarden samengevoegd worden, wat juist 1 van de positieve punten is van de huidige ontwikkelingen. Syntaxtisch gezien zijn namespaces inderdaad wat vervelend, maar het schept duidelijkheid en duidelijkheid is altijd al het sterke punt van XML geweest... Op zich is er wel wat voor te zeggen dat een namespace alleen opgegeven zou hoeven te worden als er ook daadwerkelijk een conflict is.

[mbravenboer]

Nielsz: Martinnnn! I'm confused

Ach, Otis houdt er wel van om meningen te verspreiden die vaak conflicteren met mijn meningen . Helaas is het vaak niet altijd even duidelijk waarom hij het oneens is met mijn opmerkingen of uberhaupt of we het wel echt oneens zijn .

Per definitie zijn wij het over het algemeen echter oneens .

Ik heb toch echt geleerd dat XML beschrijft wat je data is, en dat XSLT zegt hoe hij het weer moet geven.

XSLT is in principe niets anders dan een transformatie-taal voor XML. Je kunt deze transformatie-taal inzetten om vanuit data-XML een presentatie te maken (waarbij je je kunt afvragen wat nu eigenlijk data-XML is ), maar dat is absoluut niet de enige toepassing (wel de meest gebruikte waarschijnlijk). Bovendien hoef je deze presentatie dan ook weer niet percee in een browser te stoppen .

[Verwijderd]

Op woensdag 23 januari 2002 18:43 schreef mbravenboer het volgende:
[..]
Ik zei ook nadrukkelijk dat een applicatie of browser de RDDL specificatie zou kunnen gebruiken. Ik zie RDDL niet alleen als interessant voor in een browser, maar zie daar zeker wel een interessante toepassing.

Het kan zeker interessant zijn . Ik viel alleen over het woord browser etc wat te pas en te onpas wordt gebruikt, terwijl het een BIJKOMSTIGHEID is dat XML dmv XSLT naar HTML kan worden geconverteerd (en ook niet eens HTML4, maar XHTML). De kracht van XML is juist dat het hierarchische datasets (zonder/met relatie) in ascii weergeeft en dat die kunnen worden getransformeerd in andere formats dmv XSL(T). Je zult veel meer toepassingen zien van XML in de vorm van een format voor dataoverdracht tussen processen/systemen/applicaties/databases etc dan in de vorm van het genereren van HTML.

[..]
Je kunt XML en XSLT op ontzettend veel manieren gebruiken en het vind ook zijn toepassing in een webbrowser. Ik vind dit dus wel wat sterk uitgedrukt.

Nee. HTML is niet eens XML compliant. XHTML lijkt dat wel te zijn, maar een '& nbsp;' kent XML niet, XHTML wel. Dat je makkelijk data kunt omzetten in HTML dmv een XSL(T) die op HTML lijkende XML uitpoept is leuk bedacht, maar niet meer dan een truukje: de basis van XML is dat het data weergeeft in een format. Als je dat gaat omzetten naar XHTML is dat niet meer zo, je gaat nl. data omzetten naar een viewerformat, dus is de data niet meer de focus maar de opmaak. Dit is een semantisch probleem, weet ik wel, maar doet ZO'N afbreuk aan waar XML nu juist zo geschikt voor is, want (zie hierboven ook nielsz) veel mensen denken bij XML en XSLT aan het converteren van XML naar HTML. Door maar weer naar browsers te refereren maak je dat alleen maar erger. Dat was mn punt.

[..]
XSLT wordt helaas vooral gebruikt voor het transformeren naar XHTML dus dat dit vaak in samenwerking met een browser wordt genoemd verbaast mij eigenlijk absoluut niet. Zelf gebruik ik het echter vooral in andere situaties, waarin er geen relatie is met XHTML of een browser. Je kunt XSLT bijvoorbeeld heel goed gebruiken als je XML data moet inlezen in een applicatie.

Huh? 'helaas vooral' ? Ooit gekeken naar de toepassingen van XML in de dataoverdracht tussen verschillende systemen? _DAAR_ is XSL(T) voor bedacht. Niet voor HTML generatie. Dat het daar WEL voor gebruikt wordt is jammer, want je merkt aan veel dingen dat XSL(T) niet helemaal geschikt is voor het genereren van HTML (immers, HTML is niet XML compliant).

Het is wel makkelijk, mn eigen CMS werkt er ook mee, maar het is niet daarvoor bestemd. Het is bestemd voor het transformeren van XMLtree in format A naar XMLtree in format B. Als B een HTML tree is, is de samenhang tussen de data niet meer op basis van de semantiek van de data (zoals in tree A) maar op basis van hoe de browser het zal weergeven. Dit is dus van een appel een peer maken. En dus verwarringscheppend.

[Nielsz]

Op woensdag 23 januari 2002 19:02 schreef Otis een stuk met mijn naam erin
[..]

Waar ik aan denk met XML = "Ej; nu kunnen andere programma's (websites) zo makkelijk de content rippen, da's handig!";
Waar ik aan denk met XSLT = "Ej; met XSLT kan ik mooi de layout aangeven van mijn site";

Maar dit zal precies zijn wat je van me dacht

[Verwijderd]

Op woensdag 23 januari 2002 19:07 schreef Nielsz het volgende:

[..]

Waar ik aan denk met XML = "Ej; nu kunnen andere programma's (websites) zo makkelijk de content rippen, da's handig!";
Waar ik aan denk met XSLT = "Ej; met XSLT kan ik mooi de layout aangeven van mijn site";
Maar dit zal precies zijn wat je van me dacht

Ik maakte uit je reactie op dat je idd zo dacht over XSL(T) . Daar is niks mis mee hoor, er is echter zoveel meer mee te doen, waar het zelfs nog beter voor geschikt is ook (immers, als je het een webgeneration tool wilt laten zijn, had je het wel flexibeler gemaakt mbt html en daaraan gerelateerde zut als special characters denk ik dan ).

Ik noem SOAP en de verschillende business standards voor XML die zijn afgesproken voor het uitwisselen van data tussen systemen. Vroeger moest je asciifiles maken en moeilijk doen met formats en krakkemikkige readers. Nu definieer je een schema, iedereen kan een xml reader bemachtigen en de ontvanger maakt maar een XSL(T) voor het converteren naar zn eigen schema en klaar ben je.

[mbravenboer]

Otis: Ik viel alleen over het woord browser etc wat te pas en te onpas wordt gebruikt, terwijl het een BIJKOMSTIGHEID is dat XML dmv XSLT naar HTML kan worden geconverteerd

Ok, dat kan ik me voorstellen .

en ook niet eens HTML4, maar XHTML

Hoe bedoel je dat? HTML is natuurlijk wel een output method van XSLT.... Als je naar XHTML wilt transformeren moet je de xml output method gebruiken.

Je zult veel meer toepassingen zien van XML in de vorm van een format voor dataoverdracht tussen processen/systemen/applicaties/databases etc dan in de vorm van het genereren van HTML.

Dat XSLT bij XML-data-overdracht erg toepasselijk is ben ik volledig met je eens ja, maar dat wil niet zeggen dat XSLT ongeschikt is voor het transformeren naar een presentatie vorm als XHTML... XSLT vind ik eigenlijk zelfs wat beperkt voor echt zinvolle transformaties. Het is alleen voor het herschrijven van structuren echt makkelijk.

HTML is niet eens XML compliant. XHTML lijkt dat wel te zijn, maar een '& nbsp;' kent XML niet, XHTML wel.

Er zijn inderdaad een aantal zeer vervelende verschillen tussen XHTML en XML. Ik erger me bijvoorbeeld dood aan het feit dat CDATA sections commentaar zijn in XHTML . Dat wil echter niet zeggen dat XHTML nu een complete ramp is.

Dat je makkelijk data kunt omzetten in HTML dmv een XSL(T) die op HTML lijkende XML uitpoept is leuk bedacht, maar niet meer dan een truukje: de basis van XML is dat het data weergeeft in een format. Als je dat gaat omzetten naar XHTML is dat niet meer zo, je gaat nl. data omzetten naar een viewerformat, dus is de data niet meer de focus maar de opmaak.

Sorry, maar hier ben ik het echt niet mee eens. Data kan je in veel verschillende vormen aantreffen. Een presentatie-formaat kan naar mijn mening ook een vorm van data zijn. Je 'data' is dan de presentatie.

Het transformeren van XML naar XHTML, XSL-FO of wat dan ook is daarom naar mijn mening ook absoluut geen vergissing: bij deze omzetting naar presentatie zet je data om in andere data: namelijk presentatie-data.

Dit is een semantisch probleem, weet ik wel, maar doet ZO'N afbreuk aan waar XML nu juist zo geschikt voor is, want (zie hierboven ook nielsz) veel mensen denken bij XML en XSLT aan het converteren van XML naar HTML.

Tja, dat is ook niet zo gek omdat de gebruiksvorm is waarin XSLT interessant is voor mensen die niet direct met data-uitwisseling bezig zijn. Of dit nu echt afbreuk doet aan de principes van XML betwijfel ik: het is al prachtig dat er getracht wordt om data te scheiden van presentatie. De omzetting naar presentatie is gewoon een transformatie naar een andere data-vorm die heel goed in XSLT uitgedrukt kan worden. Ik zou XSLT sowieso niet al te dicht op XML willen binden.

Huh? 'helaas vooral' ? Ooit gekeken naar de toepassingen van XML in de dataoverdracht tussen verschillende systemen?

Nee, ik ben alleen wel bezig met een RMI implementatie over SOAP.

_DAAR_ is XSL(T) voor bedacht.

Dat valt volgens mij wel mee, bekijk deze slides van James Clark maar eens:
http://www.jclark.com/xml/xslt-talk.htm

Dat het daar WEL voor gebruikt wordt is jammer, want je merkt aan veel dingen dat XSL(T) niet helemaal geschikt is voor het genereren van HTML (immers, HTML is niet XML compliant).

Dat vind ik wel meevallen. Als je XHTML en CSS op de goede manier gebruikt zijn er totaal geen problemen als je XSLT inzet om naar XHTML te transformeren.

Het is wel makkelijk, mn eigen CMS werkt er ook mee, maar het is niet daarvoor bestemd. Het is bestemd voor het transformeren van XMLtree in format A naar XMLtree in format B.

Ik zie niet in waarom formaat B niet een presentatie-vorm zou mogen zijn...

Als B een HTML tree is, is de samenhang tussen de data niet meer op basis van de semantiek van de data (zoals in tree A) maar op basis van hoe de browser het zal weergeven. Dit is dus van een appel een peer maken. En dus verwarringscheppend.

Waarom moet er in XHTML een samenhang zijn tussen de data? Dat is helemaal niet nodig, want daar is XML juist voor. Bij een transformatie zet je simpelweg een XML formaat om naar een ander formaat. Ik zie geen enkele reden waarom bij deze transformatie samenhang tussen de data bewaart moet blijven. Het probleem van HTML is namelijk allang opgelost door XML. Dat wil echter niet zeggen dat je HTML niet meer moet gebruiken om XML data te presenteren.

Ik zie beide toepassingen dus als zinvol en snap eigenlijk niet waarom je een probleem hebt met het transformeren naar een presentatie-vorm.

XSL-FO vind je zeker helemaal des duivels? . (Ik vind het trouwens jammer dat dat onder dezelfde groep als XSLT valt).

[mbravenboer]

Otis: Nu definieer je een schema, iedereen kan een xml reader bemachtigen en de ontvanger maakt maar een XSL(T) voor het converteren naar zn eigen schema en klaar ben je.

Dat is inderdaad een hele goede toepassing van XSLT, maar waarom zou het de enige moeten zijn?

Misschien dat je het interessant vindt: Stratego is een zeer krachtige transformatie-taal die op dit moment in ontwikkeling is. We gebruiken deze taal onder andere om compilers in te schrijven. Het data-type van Stratego is gebaseerd op ATermen, wat enigszins te vergelijken is met XML. Het is de bedoeling om een set van componenten te maken om XML transformaties in Stratego mogelijk te maken. Je hebt zo een fraaie declaratieve taal voor transformaties die een stuk krachtiger is dan XSLT.... Je kan hem vast wel vinden in m'n signature .

[Verwijderd]

ik zeg ook niet dat het de enige is, dat is ook op te maken uit andere postings van me in deze thread: mn eigen CMS werkt met XSL(T) als templates voor het converteren van datablocks in HTML.

Wat mijn punt was, was dat er IMHO te vaak wordt gerefereerd naar html en browsers mbt XML en XSLT. Een browser is een interpretator van geconverteerde data in XML, net zoals Visual Studio.NET dat is, of een willekeurige SOAP connector. _THAT'S ALL_

[Verwijderd]

Op woensdag 23 januari 2002 20:03 schreef mbravenboer het volgende:
[..]
Dat XSLT bij XML-data-overdracht erg toepasselijk is ben ik volledig met je eens ja, maar dat wil niet zeggen dat XSLT ongeschikt is voor het transformeren naar een presentatie vorm als XHTML... XSLT vind ik eigenlijk zelfs wat beperkt voor echt zinvolle transformaties. Het is alleen voor het herschrijven van structuren echt makkelijk.

PRECIES! en rara waar het voor is bedacht? _EXACT_ wat jij schrijft in je laatste zien hierboven. .

[OTIS: HTML is niet eens XML compliant. XHTML lijkt dat wel te zijn, maar een '& nbsp;' kent XML niet, XHTML wel.]
Er zijn inderdaad een aantal zeer vervelende verschillen tussen XHTML en XML. Ik erger me bijvoorbeeld dood aan het feit dat CDATA sections commentaar zijn in XHTML . Dat wil echter niet zeggen dat XHTML nu een complete ramp is.

Oh, dat zeg ik ook niet. Ik zeg alleen: XML heeft een bepaalde syntaxis. De browser als interpretator van XML (in de vermomming van HTML) doet het erg slecht: sommige dingen kunnen niet. Dit komt omdat XML en XSLT niet bedacht zijn in 1e instantie voor waar ze nu mede voor worden ingezet: HTML generation. W3C heeft het zoals altijd goed verprutst.

Het transformeren van XML naar XHTML, XSL-FO of wat dan ook is daarom naar mijn mening ook absoluut geen vergissing: bij deze omzetting naar presentatie zet je data om in andere data: namelijk presentatie-data.

Maar terug kan niet! Je kunt nl. niet een schema X verzinnen dat de relaties tussen de data vastlegt in tree A en die tree transformeren naar HTML en dan via een schema Y dat de samenhang van de data beschrijft in die getransformeerde tree terugtransformeren met een andere XSLT.

Dit komt omdat je de data niet meer als data (values van attributen/entiteiten) gebruikt met relaties maar als losse data met opmaak zonder relaties tot elkaar: alleen de opmaak heeft relaties tot elkaar (table row/cell bv) of zelfs dat niet als je divs of spans gebruikt).

Je spreekt dus niet over dezelfde data in een ander jasje, je spreekt over iets totaal anders, nadat je de data hebt getransformeerd naar HTML middels XSLT!

Tja, dat is ook niet zo gek omdat de gebruiksvorm is waarin XSLT interessant is voor mensen die niet direct met data-uitwisseling bezig zijn. Of dit nu echt afbreuk doet aan de principes van XML betwijfel ik: het is al prachtig dat er getracht wordt om data te scheiden van presentatie. De omzetting naar presentatie is gewoon een transformatie naar een andere data-vorm die heel goed in XSLT uitgedrukt kan worden. Ik zou XSLT sowieso niet al te dicht op XML willen binden.

XSLT is niet een 'presentatie' template taal, het is een programmeertaal (functioneel nog wel ) die XML kan converteren van schema A naar schema B.

Dat men data en presentatie wil scheiden is TOTAAL irrelevant mbt XML en XSLT. XSLT wordt nu gebruikt daarvoor, omdat HTML op XML _LIJKT_ en je dus net kunt doen alsof je de XML data naar een andere XML tree converteert, maar dat is stiekem niet zo, maar die XML DOM doet zn naam eer aan en is alleen maar dom en snapt dat niet.

De omzetting naar presentatie van data is niet een simpele conversie van een format, maar het vertalen van de data naar een presentatie op basis van de betekenis van de data middels het toepassen van semantiek. En dat houdt in dat je niet een datatree overhoudt die samenhangt op basis van de data, maar op basis van de interpretatiecode! Omdat je interpretator _GEEN_ XML interpretator is, maar een HTML interpretator (de browser), is wat wordt opgeleverd niet semantisch hetzelfde, maar doe je net alsof. _DAAR_ gaat het mis: doordat XSLT continue daarmee wordt geassocieerd, wordt XSLT veelal toegepast op een manier waar het eigenlijk niet voor is bedoeld.

(ik ga even in bold want dit is de basis van mn ergernis:) )
zodat men niet een BETERE oplossing zoekt voor het converteren van DATA naar presentatiecode

Dus een oplossing die niet de nadelen van XSLT heeft, waar je niet dmv het voor de gek houden van de DOM XML naar HTML gaat converteren.

Waarom moet er in XHTML een samenhang zijn tussen de data? Dat is helemaal niet nodig, want daar is XML juist voor.

De samenhang tussen de data zoals in de bron: het XML document, is er niet meer, op geen enkele manier. De enige samenhang die er is, is de samenhang tussen de opmaakcodes, GELEGD door de interpretator, de browser, en puur met als doel de opmaak. Klinkt wellicht vergezocht, maar het is hopelijk na een paar keer herlezen wel duidelijk

XSL-FO vind je zeker helemaal des duivels? . (Ik vind het trouwens jammer dat dat onder dezelfde groep als XSLT valt).

Ik ken XSL-FO niet. Is dat XSL Functioneel Ontwerp? Fuck Off XSL?

[mbravenboer]

Otis: PRECIES! en rara waar het voor is bedacht? _EXACT_ wat jij schrijft in je laatste zien hierboven. .

Goh, dat snap ik dan tenminste . Maar ik zie nog steeds niet in waarom jij het transformeren naar XHTML niet wilt zien als het herschrijven van structuren .

Oh, dat zeg ik ook niet. Ik zeg alleen: XML heeft een bepaalde syntaxis. De browser als interpretator van XML (in de vermomming van HTML) doet het erg slecht: sommige dingen kunnen niet.

Dat zie ik toch echt niet, waarom zou een XML syntax voor HTML niet nuttig zijn? Ik zou niet weten waarom er op dat punt beperkingen zouden moeten zijn...

Dit komt omdat XML en XSLT niet bedacht zijn in 1e instantie voor waar ze nu mede voor worden ingezet: HTML generation. W3C heeft het zoals altijd goed verprutst.

Ik zie echt niet in waarom het gebruik van XSLT voor XHTML generatie nu zo'n groot probleem is. XHTML is pratisch XML en de uitzonderingsgevallen zijn allemaal vrij eenvoudig te verhelpen of niet relevant als je CSS goed gebruikt.

Maar terug kan niet!

Waarom zou dat dan moeten? Er zijn zoveel nuttige transformaties te verzinnen die niet omkeerbaar zijn. Waarom moet je je beperken tot minieme aanpassingen? Ook voor volledige herstructurering en omzetting naar andere vorm voldoet XSLT vaak uitstekend. Als ik met Stratego een transformatie beschrijf van een bepaalde taal naar een intermediate representation of assembly is dat ook vaak niet omkeerbaar. Is dat een punt? Ik zou niet weten waarom...

Dit komt omdat je de data niet meer als data (values van attributen/entiteiten) gebruikt met relaties maar als losse data met opmaak zonder relaties tot elkaar: alleen de opmaak heeft relaties tot elkaar (table row/cell bv) of zelfs dat niet als je divs of spans gebruikt).

Waarom zou dat dan vervelend moeten zijn? Het doel van deze transformatie is immers om een presentatie te maken, niet om alle relaties tussen data te behouden. Vanuit jouw benadering van data uitwisseling snap ik je argument wel, maar ik denk dat het niet altijd van toepassing is?

XSLT is niet een 'presentatie' template taal, het is een programmeertaal (functioneel nog wel ) die XML kan converteren van schema A naar schema B.

Functioneel? Hum, laten we het daar maar niet over hebben . Beweerde jij ook niet ooit dat VB lazy-evaluation kent? . XSLT is een declaratieve transformatie taal waarin je een transformatie kunt specificeren. Dat mag je als programmeertaal zien, maar ja: wat is een programmeertaal . XSLT is gebaseerd op simpele herschrijfregels, die ik absoluut niet functioneel (in de functioneel programmeren zin van het woord) zou willen noemen... Waarom gebruik je die term hier?

XSLT wordt nu gebruikt daarvoor, omdat HTML op XML _LIJKT_ en je dus net kunt doen alsof je de XML data naar een andere XML tree converteert

Mwah vind ik niet niet: XML is een syntax voor hierarchische structuren die je ook prima kunt gebruiken voor het doel van HTML4. XHTML is daar een eerste poging toe en ik vind eigenlijk dat ze aardig op de goede weg zijn. Ik zie niet in waarom XHTML nu echt een andere rol moet vervullen (dat heb ik al vaker getikt in deze draad ).

Omdat je interpretator _GEEN_ XML interpretator is, maar een HTML interpretator (de browser), is wat wordt opgeleverd niet semantisch hetzelfde, maar doe je net alsof.

Ik beweer helemaal niet dat het semantisch hetzelfde is: Als je XSLT gebruikt om data-XML naar XHTML te converteren is XHTML slechts een presentatie-vorm deze data-XML. Semantisch zit je nu in een heel ander gebied, namelijk simpelweg XHTML. XHTML is slechts een specifieke XML standaard waarvan een browser de betekenis kent. Daarom kan deze browser XHTML weergeven. Je kunt een (recente) browser uiteraard ook met behulp van CSS gaan vertellen hoe hij XML moet weergeven, maar dat is vaak minder efficient dan het transformeren naar een bekende, op XML gebaseerde standaard: XHTML.

(ik zal het even in bold laten ).

zodat men niet een BETERE oplossing zoekt voor het converteren van DATA naar presentatiecode

Als je een betere oplossing wilt, ga je er al vanuit dat XSLT niet voldoet. Maar ja: daar ben ik het dus niet mee eens . Uiteraard kan een zoektocht naar betere oplossingen nooit kwaad, maar ik kan je kritiek op een XSL transformatie oplossing nog steeds niet begrijpen. Uiteindelijk is het presenteren van data een transformatie naar een andere vorm van data: data over presentatie. XHTML of XSL Formattign Objects zijn een standaard voor presentatie-data. Omdat XHTML een presentatie-vorm is die zeer breed geaccepteerd is, vind ik dat een uitstekende oplossing.

waar je niet dmv het voor de gek houden van de DOM XML naar HTML gaat converteren.

Kan je mij nu eens goed uitleggen waarom je vind dat je voor de gek gehouden wordt? Ik zie namelijk echt niet in waarom je XHTML niet als just-another XML standaard wilt zien . Er zijn wat kleine problemen, maar die zijn niet onoverkomelijk toch?

De samenhang tussen de data zoals in de bron: het XML document, is er niet meer, op geen enkele manier. De enige samenhang die er is, is de samenhang tussen de opmaakcodes, GELEGD door de interpretator, de browser, en puur met als doel de opmaak. Klinkt wellicht vergezocht, maar het is hopelijk na een paar keer herlezen wel duidelijk

Ik begrijp zeker wel waar je heen wilt, maar ik begrijp niet waarom er nu percee nog steeds een samenhang moet zijn: je bevindt je namelijk in een volledig andere data-vorm. Als jij samenhang tussen data wilt behouden moet je simpelweg niet transformeren naar XHTML.

Ik ken XSL-FO niet. Is dat XSL Functioneel Ontwerp? Fuck Off XSL?

Haha , nee: XSL Formatting Objects, een derde tak van de XSL standaard. Je beschrijft hiermee zeer exact een layout. Je kunt een XML document bijvoorbeeld transformeren naar XSL Formatting Objects. Daarna kan dat met behulp van bijvoorbeeld FOP van Apache omgezet worden naar PDF of RTF. Moet duivels op je overkomen toch? .

_{leuke en prettige discussie trouwens}

[CyberSnooP]

Om stiekem toch weer een klein beetje terug on-topic te gaan.

Komt het er niet op neer dat RDDL gewoon een manier is om te voorkomen dat je je XML vol moet stoppen met allerlei URLs? Dus is RDDL een afkortingsmechanisme?

Of kan het ook nog zo zijn dat je niet eens naar de RDDL hoeft te verwijzen en je browser zelfstandig op zoek gaat naar een RDDL voor jouw namespace?

_{Ik hoefde niet eens naar de topicstarter te kijken om te zien wie het was}

[mbravenboer]

CyberSnooP: Komt het er niet op neer dat RDDL gewoon een manier is om te voorkomen dat je je XML vol moet stoppen met allerlei URLs? Dus is RDDL een afkortingsmechanisme?

Zo zou je het kunnen zien ja... RDDL gaat in principe uit van het standpunt dat er ontzettend veel resources bij een namespace betrokken zijn. Een stylesheet en een xml-schema opnemen in je document gaat nog, maar daarna wordt het toch echt te gek. RDDL verzamelt deze resources op 1 plaats en voorkomt dat het in elk XML document wordt gedupliceerd of vergeten kan worden.... Het grote voordeel is dat je je ook niet op een bepaalde toepassing hoeft te richten: de toepassing kan zelf uitzeken welke resources er nodig zijn, dat bepaalt niet de aanbieder van de XML bron. .

Of kan het ook nog zo zijn dat je niet eens naar de RDDL hoeft te verwijzen en je browser zelfstandig op zoek gaat naar een RDDL voor jouw namespace?

De namespace is de verwijzing naar een RDDL specificatie, op zoek gaan is dus niet zo lastig . Er wordt ook niet op een of andere intelligente wijze gezocht naar een RDDL: de namespace (die je toch al vaak moet opgeven) is de URL van de RDDL .

[CyberSnooP]

De Topicstarter meende te moeten zeggen:
Wat wil je nu eigenlijk van me?

Zoals je merkt heb ik de ontwikkeling van RDDL niet echt gevolgd, dus mijn vraag: wie heeft dit wel gevolgd en kan misschien iets vertellen over de redenen waarom de support niet echt op gang is gekomen? Weet iemand iets over plannen voor RDDL support in Mozilla? Ik kon namelijk helemaal niets vinden op Bugzilla. Zou het zinvol zijn om RDDL een schop te geven en een bug te posten op Bugzilla?

Hoewel ik me persoonlijk weinig met XML bezig hou lijkt met RDDL een zinvolle verduidelijking van de XML-standaard. Het lijkt mij dus ook nuttig om Mozilla dat te laten leren, zeker omdat ik gok dat het voor de Mozilla bouwers niet al te moelijk moet zijn om iets dergelijks te implementeren.

Een Feature Request (bug?) lijkt me op z'n plaats, en ik ben best bereid voor die bug te stemmen hoor
________________________________________________

Klein ander vraagje:
Komt er nou ook iets fatsoenlijks om XML --> XHTML om te zetten? Voor zover ik het gezien (en gelezen hier) is XSLT de enige bruikbare methode, maar de constructies die ik af en toe in voorbeelden zie maken het al met al niet echt heel veel overzichtelijker.

_{Ik heb toch niet voor niks op mbravenboer gestemd als Lite-mod, blijkt wel uit dit topic}

[mbravenboer]

CyberSnooP: Het lijkt mij dus ook nuttig om Mozilla dat te laten leren, zeker omdat ik gok dat het voor de Mozilla bouwers niet al te moelijk moet zijn om iets dergelijks te implementeren.

Inderdaad. Ik zal een dezer dagen eens informeren bij de mensen achter RDDL hoe ze daar tegenover staan. Zij kunnen mij vast ook vertellen hoe het staat met de ontwikkelingen rond RDDL. Ik begrijp dat het W3C nog steeds wel licht bezig is met RDDL, dus als er een officiele W3C variant/vervolg gaat komen is een RFE voor Mozilla niet zo zinvol....

maar de constructies die ik af en toe in voorbeelden zie maken het al met al niet echt heel veel overzichtelijker.

Welke constructies staan je dan niet aan?

De syntax van XSLT is af en toe nogal *censuur*, maar de opzet van structurele recursie vind ik zelf eigenlijk uitermate geslaagd. XPath vind ik ook prettig. Ik ben eigenlijk bij simpele herstructureringen nog niet echt problemen tegengekomen.

Zie uiteraard ook de andere XSLT thread en mijn verhaal over Stratego: [topic=389819/1/25] .

Er zal ook voorlopig zeker geen officiele fundamenteel andere variant komen. XPath en XSLT zijn mateloos populair en behoorlijk geaccepteerd. XSLT 2.0 en XPath 2.0 zijn volop in ontwikkeling en brengen een behoorlijk aantal verbeteringen. Voorlopig zal het dus neerkomen op het verbeteren van de huidige standaard .

[GiLuX]

Op woensdag 23 januari 2002 02:22 schreef mbravenboer het volgende:
... Ik dacht: verrek, een acroniem die mij is ontgaan! ...

deze ken je vast ook nog niet:
MetaL
oftewel MetaL - A XML based Meta-Programming language.

deze kerel (manuel lemos) heeft het idee gekregen om een soort van abstracte programeer taal te maken die je in xml schrijft.
als je dan klaar bent laat je er een parser op los (zeg maar zoals je xslt op xml los laat) die het hele zooitje naar taal van keuze compileert, eg: c,c++,java,etc...

geen idee wat hier terecht van moet komen maar hij is er zeer serieus over.

het idee is interessant maar ik vraag me af of dit ook praktisch uitvoerbaar is.

http://www.meta-language.net/

[mbravenboer]

GiLuX: MetaL

Haha . Ik zal de site eens bekijken.

In ieder geval ga ik nooit imperatief programmeren in een abstract syntax, dat laat ik wel aan Lisp gebruikers over .

Zonder dat ik de site bekeken hebt lijkt het mij voorlopig dat je ontzettend veel problemen met libraries en verschillen tussen paradigma's krijgt.

De gedachte is trouwens niet zo heel erg origineel: het is in compilers steeds vaker gebruikelijk om eerst een taal om te zetten naar een 'intermediate representation' die je voor verschillende talen en platformen kunt gebruiken. Je krijgt zo een scheiding tussen een front-end en een back-end. Als je je eenmaal een back-end hebt geschreven voor een bepaald platform kan je dus automatisch alle talen die naar die IR te vertalen zijn compileren naar dat platform/

[mbravenboer]

Hum ik heb slides bekeken, maar daar kon ik niet veel uit opmaken helaas.

Wel vond ik de opmerking dat XML zo ideaal is omdat je geen parser meer nodig hebt vrij zorgwekkend voor een programmeertaal.

Ik kijk nog ffies verder .

[GiLuX]

Op woensdag 23 januari 2002 23:41 schreef mbravenboer het volgende:
Hum ik heb slides bekeken, maar daar kon ik niet veel uit opmaken helaas.

Wel vond ik de opmerking dat XML zo ideaal is omdat je geen parser meer nodig hebt vrij zorgwekkend voor een programmeertaal.

Ik kijk nog ffies verder .

het komt allemaal net iets te stuntelig over,
maar wie weet....

ik heb het idee opgevat om j2ee voor php te maken,
dus voor dat ik dit heerschap voor maf ga uitmaken...

[Rense Klinkenberg]

Op woensdag 23 januari 2002 23:26 schreef GiLuX het volgende:
deze ken je vast ook nog niet:
MetaL
oftewel MetaL - A XML based Meta-Programming language
...

Als we zo bezig gaan, moeten we natuurlijk rxml. Dat is een server-side scripting taal (net ziets als php, enz), maar dan compleer xml valid. Het taaltje wordt perfect begrepen door de Roxen webserver.

het leuke van dit alles is, dat de makers zeggen dat rxml al bestond voordat xml pas echt bestond (de 'xml' uit rxml staat ook niet voor het gewone xml).

<edit>
Een stukje uit de manual die ik nu ook maar eens aan het lezen ben:

RXML

RXML is Roxens own "marker system" for many of its modules. RXML, RoXen Makro Language (it was invented before XML), is a functional, serverside, XML compliant scripting language that easily integrates itself with web content. Since its syntax is already familiar for many it is often very easy to learn. Its tight integration with the XML in the pages enables the module programmer to keep as little HTML as possible in the program code, thus leaving more creative freedom to the web designer, i.e. a good separation between layout and functional code.

</edit>

[mbravenboer]

Ik heb een mailtje gestuurd naar de editors van RDDL. Het leek me wel verstandig om deze mensen even te raadplegen voordat ik een RFE plaatst.

Hier de tekst:

Dear RDDL editors,

Just recently I've learned about your great work on RDDL. RDDL sounds very interesting to me. I've discussed RDDL with some people and they like your proposals too. Unfortunately most of the articles on RDDL date from the first quarter of 2001. I've found out that the W3C has been interested in RDDL but nowadays I cannot find anything going on related to RDDL at the W3C.

The main browsers do not (and are not planning to) support RDDL and there are just a few standards using a RDDL document at the URL of their namespace. Certainly W3C doesn't do this although there once was a RDDL specification at the URL of the XML-Schema namespace?

I think this is a great pity and I hope I see this wrong.

Can you please point me to information or inform me on the activity on RDDL or other related proposals? What is happening with RDDL?

I'm thinking about creating a request for enhancement for Mozilla. It would be great if this excellent browser could create a chance to keep RDDL alive and kicking. Does this make sense to you? Would you support such a request?

Thanks in advance for any information or comments,

Martin Bravenboer,
Master Student Computer Science,
The Netherlands.

[mbravenboer]

Tim Bray, 1 van de editors heeft geantwoord:

>Can you please point me to information or inform me on the activity on RDDL or other related proposals? What is happening with RDDL?

There's been a flurry of interest in recent weeks on the xml-dev mailing list (archives online at xml.org), and after some months of silence, your email is one of several I've received in the last 2 weeks on RDDL. So maybe there's a cosmic force at work here

>I'm thinking about creating a request for enhancement for Mozilla. It would be great if this excellent browser could create a chance to keep RDDL alive and kicking. Does this make sense to you? Would you support such a request?

Yep. Of course, the best way to get something into Mozilla is to write the code yourself. -Tim

[CyberSnooP]

Op donderdag 24 januari 2002 20:06 schreef mbravenboer het volgende:
Tim Bray, 1 van de editors heeft geantwoord:

Yep. Of course, the best way to get something into Mozilla is to write the code yourself. -Tim

Aangezien je redelijk in de kern van XML-parsing ingrijpt lijkt me dat niet helemaal waar. Als Mozilla leek heb je geen idee waar je moet beginnen. Ik zou het aan een van de mensen van Mozilla zelf voorleggen. Als die geen intresse tonen dan moet 'ons' hard gaan coden

[mbravenboer]

CyberSnooP: Aangezien je redelijk in de kern van XML-parsing ingrijpt lijkt me dat niet helemaal waar. Als Mozilla leek heb je geen idee waar je moet beginnen.

Zit wat in, maar dan vooral omdat je vrij veel componenten bij elkaar moet trekken denk ik: je moet weten op welke plek en hoe je moet gaan beslissen om naar een RDDL te gaan zoeken, je moet de RDDL file inlezen en zoeken naar een stylesheet. Daarna moet je weten hoe je die gaat toepassen...

Voor iemand die er 'in' zit een fluitje van een cent, voor een leek een vrij grote klus...

[CyberSnooP]

Op donderdag 24 januari 2002 20:45 schreef mbravenboer het volgende:
Voor iemand die er 'in' zit een fluitje van een cent, voor een leek een vrij grote klus...

Zeg nooit fluitje, want zoals ik het zie is die RDDL ook gewoon een XML file, maar die mag dan opeens weer geen RDDL inzichzelf toepassen etc..

Maar als er een open-source held hier is die zich geroepen voelt? Evt. kun je voorleggen dat er met wat tips ook wel door anderen geschreven kan worden, al zal ik diegene niet zijn

[mbravenboer]

CyberSnooP: Maar als er een open-source held hier is die zich geroepen voelt?

Tja, als het Java was deed ik het zelf wel even... in C++ voel ik me een stuk minder thuis .

[tomato]

mbravenboer: Tja, als het Java was deed ik het zelf wel even... in C++ voel ik me een stuk minder thuis .

Misschien Arien even lief aankijken?

[mbravenboer]

tomato: Misschien Arien even lief aankijken?

Hum, zou niet gek zijn . Is die een beetje op de hoogte van de interne werking van Mozilla?

[tomato]

mbravenboer: Hum, zou niet gek zijn . Is die een beetje op de hoogte van de interne werking van Mozilla?

Ik weet het eigenlijk niet. Ik dacht dat hij er wel eens over zat te denken om mee te dev'en aan Mozilla, maar misschien had ik zijn woorden verkeerd begrepen.

Maar hij blijft natuurlijk altijd een Mozilla sympathisant, hij heeft het er regelmatig over (en C++ moet voor hem geen probleem zijn geloof ik)

[mbravenboer]

De tweede editor heeft ook geantwoord:

Martin,

Thanks for your interest.

> Can you please point me to information or inform me on the activity on
> RDDL or other related proposals? What is happening with RDDL?

The RDDL proposal is fairly stable at this point and steadily gaining momentum. Browser support would be terrific. You may have noticed the recent flurry of interest on the XML-DEV list, where the latest news and issues
with RDDL are available http://lists.xml.org/archives/xml-dev/

> I'm thinking about creating a request for enhancement for Mozilla. It
> would be great if this excellent browser could create a chance to keep
> RDDL alive and kicking. Does this make sense to you? Would you support
> such a request?

Absolutely makes sense and I certainly would support. This generally means adding simple XLink support to the browser which would be an important thing all around. Keep me posted.

Jonathan

Ik zal eens kijken of ik een RFE kan opstellen en we moeten Arien even iets explicieter naar dit topic schoppen .