Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Ik gebruik tegenwoordig regelmatig XML als configuratie opslag, presentaties klaar voor transformatie (bij sites e.d.) en uitwisseling over internet ... alleen ik heb tot op heden nog nooit direct gebruik gemaakt van schema's (shame on you).
Ik denk dat het gewoon gemakszucht is, voor veel projecten die ik doe is het niet
noodzakelijk dat andere programmeurs/developers zich met mijn XML bezig houden, dus vind ik het niet nodig om dit in stricte richtlijnen in te richten.
En ik denk dat dit voor meerdere mensen hier geldt, vandaar de weinig topics over xml schema's. Ik vind ze namelijk absoluut NIET makkelijk (waarbij een DTD de kroon spant) voor zover ik er naar heb gekeken.
Ik denk dat het gewoon gemakszucht is, voor veel projecten die ik doe is het niet
noodzakelijk dat andere programmeurs/developers zich met mijn XML bezig houden, dus vind ik het niet nodig om dit in stricte richtlijnen in te richten.
En ik denk dat dit voor meerdere mensen hier geldt, vandaar de weinig topics over xml schema's. Ik vind ze namelijk absoluut NIET makkelijk (waarbij een DTD de kroon spant) voor zover ik er naar heb gekeken.
Ik gebruik voor validatie eigenlijk alleen RELAX NG, omdat ik XML Schema onnodig ingewikkeld (of beperkend, je moet hiertussen kiezen) vind.
Alleen voor entities gebruik ik natuurlijk DTD's (W3C XHTML DTD is alles wat ik nodig heb), default values en notations gebruik ik niet.
Ook maak ik net als Orphix lang niet altijd een schema voor een XML formaat dat ik gebruik, vooral doordat ik de enige ben die er gebruik van maakt en er zelf vaak al vrij zeker van ben dat mijn XML 'goed' is. Gewoon luiheid dus
Alleen voor entities gebruik ik natuurlijk DTD's (W3C XHTML DTD is alles wat ik nodig heb), default values en notations gebruik ik niet.
Ook maak ik net als Orphix lang niet altijd een schema voor een XML formaat dat ik gebruik, vooral doordat ik de enige ben die er gebruik van maakt en er zelf vaak al vrij zeker van ben dat mijn XML 'goed' is. Gewoon luiheid dus
Je hoort inderdaad wel vaker dat het maken van een schema als onnodig wordt gezien. Op zich is dit in veel situaties ook wel zo. Het wel maken van een schema heeft misschien wel het voordeel dat je verplicht wordt om goed na te denken over de structuur van je XML formaat. Met name ben je dan verplicht om na te denken over het onderscheid tussen non-terminals en productie-regels (typen en elementen in W3C XML Schema), wat zeker nuttig is.
Ik heb me regelmatig afgevraagd of het W3C met z'n XML Schema het hele fenomeen van schema talen voor XML geen ernstige schade toebrengt. Het werkt namelijk niet bepaald stimulerend, terwijl dat wel hard nodig is. Schema's worden naar mijn idee met name gemaakt omdat het gewoon pokkewerk is in W3C XML Schema en in iets mindere mate ook in DTD.
Dat het maken van een schema toch wel leuk kan zijn blijkt denk ik wel uit het verschil tussen de voorbeelden in RELAX NG en W3C XML Schema in dit topic van gisteren: [rml][ XML Schema] Conditioneel uitsluiten van kind-element;[/rml]
Er bestaan alternatieve schema talen, waarvan RELAX NG ongetwijfeld de bekendste en aantrekkelijkste is, maar omdat deze niet van het W3C komen, worden ze ook niet echt breed geaccepteerd. Veel mensen die RELAX NG voor het eerst bekijken krijgen nogal een 'aha erlebnis' (uiting van aangename verrassing, blijde voldoening
). RELAX NG is conceptueel zeer eenvoudig en begrijpelijk en daarom uitermate populair bij de mensen die er kennis van hebben. De compacte syntax (= niet XML syntax) is ook nogal een opluchting.
Ik loop met deze post het risico dat dit een soort promotie topic wordt voor RELAX NG, maar ik hoop dat er nog wat meer gebruikservaringen komen van schema talen voor XML
.
Ik heb me regelmatig afgevraagd of het W3C met z'n XML Schema het hele fenomeen van schema talen voor XML geen ernstige schade toebrengt. Het werkt namelijk niet bepaald stimulerend, terwijl dat wel hard nodig is. Schema's worden naar mijn idee met name gemaakt omdat het gewoon pokkewerk is in W3C XML Schema en in iets mindere mate ook in DTD.
Dat het maken van een schema toch wel leuk kan zijn blijkt denk ik wel uit het verschil tussen de voorbeelden in RELAX NG en W3C XML Schema in dit topic van gisteren: [rml][ XML Schema] Conditioneel uitsluiten van kind-element;[/rml]
Het grootste probleem van DTD is dat het absoluut niet meer aansluit bij de huidige stand van zaken van XML. W3C XML Schema zou de opvolger van DTDs moeten worden, maar is nogal een complexe toestand en wordt met name daarom niet bepaald breed geaccepteerd.Orphix: Ik vind ze namelijk absoluut NIET makkelijk (waarbij een DTD de kroon spant) voor zover ik er naar heb gekeken.
Er bestaan alternatieve schema talen, waarvan RELAX NG ongetwijfeld de bekendste en aantrekkelijkste is, maar omdat deze niet van het W3C komen, worden ze ook niet echt breed geaccepteerd. Veel mensen die RELAX NG voor het eerst bekijken krijgen nogal een 'aha erlebnis' (uiting van aangename verrassing, blijde voldoening
Ik loop met deze post het risico dat dit een soort promotie topic wordt voor RELAX NG, maar ik hoop dat er nog wat meer gebruikservaringen komen van schema talen voor XML
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Met name wanneer er gegevens tussen verschillende applicaties uitgewisseld worden is een XML Schema (of RELAX NG) onontbeerlijk. Wanneer je er goed gebruik van maakt kan het jezelf en anderen veel werk schelen.
We hebben ooit een applicatie gebouwd die xml van software van derden ontvangt. De gegevensleveranciers hebben dan genoeg aan een url en het XML Schema om een koppeling tot stand te kunnen brengen (mits ze een beetje wijs uit het Schema kunnen worden
).
De gegevens die aankomen worden op de server gevalideerd aan de hand van het XML Schema. Dit bespaart je echt een hoop triviale checks die je normaliter zou moeten programmeren.
(Beetje offtopic)
Zou het trouwens mogelijk zijn om na de validatie het XPath van de plek waar de fout zit weer terug te geven in een XML foutbericht? Voor mijn gevoel zou je dan een mooie foutafhandeling kunnen bouwen...
We hebben ooit een applicatie gebouwd die xml van software van derden ontvangt. De gegevensleveranciers hebben dan genoeg aan een url en het XML Schema om een koppeling tot stand te kunnen brengen (mits ze een beetje wijs uit het Schema kunnen worden
De gegevens die aankomen worden op de server gevalideerd aan de hand van het XML Schema. Dit bespaart je echt een hoop triviale checks die je normaliter zou moeten programmeren.
(Beetje offtopic)
Zou het trouwens mogelijk zijn om na de validatie het XPath van de plek waar de fout zit weer terug te geven in een XML foutbericht? Voor mijn gevoel zou je dan een mooie foutafhandeling kunnen bouwen...
Voor validatie binnen eigen applicaties staat niks het gebruik van RELAX NG in de weg denk ik.mbravenboer schreef op 14 september 2002 @ 14:58:
Er bestaan alternatieve schema talen, waarvan RELAX NG ongetwijfeld de bekendste en aantrekkelijkste is, maar omdat deze niet van het W3C komen, worden ze ook niet echt breed geaccepteerd.
Anders wordt het wanneer je dus met een RELAX NG specificatie komt aanzetten bij anderen. Ik hoor ze nu al: "was dat voor standaard? ondersteunt Microsoft het?"
Ik baal ook wel een beetje van die complexiteit van XML Schema, maar voorlopig is het binnen real-world projecten de enige mogelijkheid vrees ik...
Dat is inderdaad geen onaardig ideetijn: Zou het trouwens mogelijk zijn om na de validatie het XPath van de plek waar de fout zit weer terug te geven in een XML foutbericht? Voor mijn gevoel zou je dan een mooie foutafhandeling kunnen bouwen...
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Dan moet je zeggen: "Das van James Clark, de man achter XSLT"tijn: "was dat voor standaard?"
Verder ben ik het wel eens met je opmerking over het gebruik van RELAX NG. Je zult vast wel begrijpen dat ik het zelf gebruik in mijn software
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Op dit moment gebruik ik nog Schema`s om mijn XML te valideren en ik heb er verder niet echt problemen mee (doe er op dit moment ook niet zoveel mee). In het begin was het even lastig, maar ik heb er nu een aantal gemaakt en daarin kan ik altijd terug kijken hoe ik het heb gedaan.
Misschien dat ik in de toekomst wel eens een keer RELAX NG ga proberen, maar voorlopig voldoet Schema nog goed genoeg.
Misschien dat ik in de toekomst wel eens een keer RELAX NG ga proberen, maar voorlopig voldoet Schema nog goed genoeg.
Misschien komt het doordat ik geen 'echte' programmeur ben (eerder autodidact die-hard codeprutser), maar ik vind XML validatie maar lastig. In de meeste gevallen wanneer ik XML gebruik heb ik weinig te maken met andere programmeurs en/of hun software. Dus wanneer ik dan klaar ben mijn componenten te schrijven, zijn die 100% compatible met het XML formaat dat deze componenten verbindt. Tot die tijd veranderd de XML opbouw bijna dagelijks, dus is het bijhouden van een Schema alleen maar overhead. Ik kan me nog herinneren dat ik een hele dag bezig was geweest met een DTD te defineren, en toen ik de eerste dag met coden begon bleek het DTD waardeloos omdat het coden op zich betere inzichten verschafte in de meest efficiente opbouw. Nou kun je zeggen, "ontwerp je softwarecomponenten dan ook eerst netjes vantevoren", maar daarbij heb ik precies hetzelfde probleem dat ik pas inzicht krijg over de beste architectuur wanneer ik het door schade en schande leer.
Het nut ervan is me echter volstrekt duidelijk. Paar weken geleden ben ik samen met een collega met Apache Cocoon aan het prutsen geweest, en dan zouden we het werk zo verdelen dat ik vanaf een SQL database tot een XML formaat zou komen, dan een stuk logica met weer een XSLT transform erachter, en m'n collega zou dat dan oppikken en er XHTML van bouwen. Gevolg was dat we de hele tijd aan het bakkeleien waren over de vorm van de XML die ik moest opleveren en hij transformeren. Best lastig om zo samen te werken zonder 'standaard'. Maarja een Schema afspreken...al dat XML gedoe was voor m'n collega zowieso al helemaal nieuw, dus jah om nou ook dat er nog bij te doen. En toen het eenmaal gelukt was, was het Schema ook niet meer nodig en hebben we volgens de ontstane stuctuur nog een paar gelijksoortige pipelines in elkaar gebrouwd. Kan ik nu wel een Schema gaan maken, maar dikke kans dat het Schema weer aangepast moet worden wanneer er nieuwe componenten bij komen.
Ja als het een keer helemaal klaar is en het is zo'n cool ding geworden als wat wij nu in ons hoofd hebben, dan kunnen we het misschien open source maken of zelfs verkopen, en dan is een Schema wel handig voor degenen die er mee verder willen of willen SOAPen met het systeem, maar ja zover is het nog lang niet..
Het nut ervan is me echter volstrekt duidelijk. Paar weken geleden ben ik samen met een collega met Apache Cocoon aan het prutsen geweest, en dan zouden we het werk zo verdelen dat ik vanaf een SQL database tot een XML formaat zou komen, dan een stuk logica met weer een XSLT transform erachter, en m'n collega zou dat dan oppikken en er XHTML van bouwen. Gevolg was dat we de hele tijd aan het bakkeleien waren over de vorm van de XML die ik moest opleveren en hij transformeren. Best lastig om zo samen te werken zonder 'standaard'. Maarja een Schema afspreken...al dat XML gedoe was voor m'n collega zowieso al helemaal nieuw, dus jah om nou ook dat er nog bij te doen. En toen het eenmaal gelukt was, was het Schema ook niet meer nodig en hebben we volgens de ontstane stuctuur nog een paar gelijksoortige pipelines in elkaar gebrouwd. Kan ik nu wel een Schema gaan maken, maar dikke kans dat het Schema weer aangepast moet worden wanneer er nieuwe componenten bij komen.
Ja als het een keer helemaal klaar is en het is zo'n cool ding geworden als wat wij nu in ons hoofd hebben, dan kunnen we het misschien open source maken of zelfs verkopen, en dan is een Schema wel handig voor degenen die er mee verder willen of willen SOAPen met het systeem, maar ja zover is het nog lang niet..
Een schema is natuurlijk niet alleen bedoeld voor validatie, maar met name ook voor documentatie. Programmeertalen worden ook gedocumenteerd met behulp van een grammatica, maar die grammatica wordt ook gebruikt om een parser te schrijven die controleert of een stuk code voldoet aan de grammatica.
Incrementeel ontwerp van een XML formaat is op zich helemaal niets mis mee. Het spreekt natuurlijk voor zich dat je niet volledig achter de tekentafel een formaat kunt ontwerpen, net zoals je niet tot in detail een stuk software kan gaan ontwerpen.
Ik denk dat hetgene wat je het meeste mist als je geen schema's maakt de typering is. Je ziet in een XML document namelijk helemaal geen types, maar alleen maar toepassingen van productie-regels (die een type produceren). Dit is in feite hetzelfde verhaal als voor normale context-vrije programmeertalen waar je bijvoorbeeld expressions en statements hebt.
Als je geen rekening houdt met deze non-terminals, typering of hoe je het ook wilt noemen, ontstaat er al snel een wildgroei een constructies. Omdat je geen typen onderscheid let je er ook niet op en daardoor kunnen er snel een hoop 'zinloze typen' ontstaan. Als je eerst onderscheid maakt in de typen van constructies die er nodig zijn in een XML formaat. Kan je je formaat misschien logischer en duidelijker opzetten.
Maar ja, voor simpele beschrijvingen van boeken-winkels, beurskoersen en orders is dat misschien wel niet zo heel erg noodzakelijk
.
Incrementeel ontwerp van een XML formaat is op zich helemaal niets mis mee. Het spreekt natuurlijk voor zich dat je niet volledig achter de tekentafel een formaat kunt ontwerpen, net zoals je niet tot in detail een stuk software kan gaan ontwerpen.
Ik denk dat hetgene wat je het meeste mist als je geen schema's maakt de typering is. Je ziet in een XML document namelijk helemaal geen types, maar alleen maar toepassingen van productie-regels (die een type produceren). Dit is in feite hetzelfde verhaal als voor normale context-vrije programmeertalen waar je bijvoorbeeld expressions en statements hebt.
Als je geen rekening houdt met deze non-terminals, typering of hoe je het ook wilt noemen, ontstaat er al snel een wildgroei een constructies. Omdat je geen typen onderscheid let je er ook niet op en daardoor kunnen er snel een hoop 'zinloze typen' ontstaan. Als je eerst onderscheid maakt in de typen van constructies die er nodig zijn in een XML formaat. Kan je je formaat misschien logischer en duidelijker opzetten.
Maar ja, voor simpele beschrijvingen van boeken-winkels, beurskoersen en orders is dat misschien wel niet zo heel erg noodzakelijk
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Pagina: 1