[XML] Hierarchie, consequent blijven of flexibel gebruiken?

[r0bert]

Ik denk niet dat er specifiek een oplossing is voor mijn "probleem", maar goede argumenten zijn heel erg welkom. Waar ik mee zit is de structuur, of hierarchie hoe je het noemen wilt, van mijn xml-data. Op zich is het geen probleem, en zijn er denk ik niet echt geschreven regels voor, meer dat ik het netjes en handig wil hebben. Eerst maar eens een voorbeeldje:

XML:

<data>
   <forum>
       <topics>
            <topic>wie weet</topic>
            <topic>wat hier</topic>
            <topic>moet staan</topic>
       </topics>
   </forum>
</data>

en

XML:

<data>
    <topics>
         <topic>wie weet</topic>
         <topic>wat hier</topic>
         <topic>moet staan</topic>
   </topics>
</data>

Wat is nou beter? Consequent mijn structuur (schema?) aan blijven houden? terwijl de forum tags (en evt diepere niveau's) vrijwel nutteloos zijn?

Ik heb het geprobeerd te vergelijken met een boek met hoofdstukken, paragrafen e.d. maar dat doet me nog niet echt overtuigen van een van beide methodes...

[ Voor 49% gewijzigd door r0bert op 18-12-2005 19:46 ]

[NMe]

Heeft een forum betekenis? Kunnen er voor een data-node meerdere forum-nodes zijn? In dat geval neem je de forum-node ook op, anders niet. Wat beter is, is dus afhankelijk van de situatie.

[r0bert]

Als er meerdere forumnodes zouden zijn is het noodzakelijk om deze op te nemen. In mijn geval stel ik het meer als een keuze. Je verwacht een paragraaf ook binnen een hoofdstuk/sectie, toch? of juist niet? Uit de xhtml, binnen een ul verwacht je een li. Moet je dat hierboven bijvoorbeeld (zijn ook andere voorbeelden te verzinnen) ook zo stellen. Het topic is immers onderdeel van het topic.

Aan de andere kant kan ik me voorstellen dat het vrij "nutteloos" is, omdat het zoals ik het hier zie, weinig directe toegevoegde waarde heeft.

Mbt stylesheets weet ik ook niet zozeer of methode 1 nu een voordeel of een nadeel zou zijn. Ene kant kun je zo veel specifieker zijn, maar of dat nu + of - is

[joopst]

ik zou zeggen dat de structuur er voor is om je data een beetje gestructureerd te houden. Een xml is is goed gestructureerd als hij voldoende structuur aanbrengt :-)

Zo stel je nu de vraag over structuur binnen 1 file, maar zo zou je je ook af kunnen vragen welke data allemaal in deze file moet. Alleen forum-data of ook bijv. cms-data..

Als er alleen forum-topics in de xml komen dan zou ik het nog kleiner maken:

code:

       <topics>
            <topic>wie weet</topic>
            <topic>wat hier</topic>
            <topic>moet staan</topic>
       </topics>

[frickY]

r0bert schreef op zondag 18 december 2005 @ 20:04:
Uit de xhtml, binnen een ul verwacht je een li

Technisch gezien is het andersom. Bij een <li> verwacht je altijd een <ul>. Die ul gebruik je namelijk omdat je die <li> wilt gebruiken, en niet andersom. En die <li> kan niet zonder <ul>
In het geval van XML gaat dat niet op, aangezien je daar alle tags zelf verzint. Je kunt je forum-node dus gewoon achterwege laten als deze geen toegevoegde waarde heeft

[bodiam]

r0bert schreef op zondag 18 december 2005 @ 19:35:
Wat is nou beter? Consequent mijn structuur (schema?) aan blijven houden? terwijl de forum tags (en evt diepere niveau's) vrijwel nutteloos zijn?

Als de elementen op dit moment geen functie vertegenwoordigen, zou ik zeggen: weg er mee. Mijn ervaring is dat het nadenken over dit soort dingen teveel tijd kost, en te weinig opbrengt. Is het niet goed, pas het later aan. Misschien dat je over enkele weken een bepaald inzicht heb verkregen waardoor een diepere boom wel toegevoegde waarde vertegenwoordigd, maar ik zou geen dingen ontwikkelen die je (nu) toch niet gebruikt.

[Erkens]

bodiam schreef op maandag 19 december 2005 @ 11:58:
maar ik zou geen dingen ontwikkelen die je (nu) toch niet gebruikt.

Ik zou juist wel nadenken over de (nabije) toekomst.

Dus consequent flexibel werken
Door juist die structuur te houden forum->topics->topic kan je ten alle tijden extra informatie mee sturen in je XML ongeacht welk deel van de applicatie het ontvangt. Zodra je dan die forum node weghaalt is dit niet meer het geval en ben je minder flexibel.

frickY schreef op maandag 19 december 2005 @ 08:49:
In het geval van XML gaat dat niet op, aangezien je daar alle tags zelf verzint. Je kunt je forum-node dus gewoon achterwege laten als deze geen toegevoegde waarde heeft

Waarom zou je met een eigen XML geen regels kunnen opstellen zoals XHTML ook heeft?
Die forum node heeft wel degelijk een functie, immers deze geeft aan waar die topics zich bevinden: in een forum.

[PhoeniX-]

-NMe- schreef op zondag 18 december 2005 @ 19:52:
Heeft een forum betekenis? Kunnen er voor een data-node meerdere forum-nodes zijn? In dat geval neem je de forum-node ook op, anders niet. Wat beter is, is dus afhankelijk van de situatie.

Exact. Ik zou het op eenzelfde manier bekijken als het modelleren van een database.

[bodiam]

Erkens schreef op maandag 19 december 2005 @ 12:43:
Ik zou juist wel nadenken over de (nabije) toekomst.

Ik heb ook nooit gezegd dat ik dat niet zou doen. Ik zeg alleen maar dat je geen nutteloze dingen moet gaan doen.

Dus consequent flexibel werken
Door juist die structuur te houden forum->topics->topic kan je ten alle tijden extra informatie mee sturen in je XML ongeacht welk deel van de applicatie het ontvangt. Zodra je dan die forum node weghaalt is dit niet meer het geval en ben je minder flexibel.

Het voegt niets toe. Zodra je extra informatie gaat meesturen zullen applicaties die hiermee omgaan ook aangepast moeten worden. Ik vind dit dus niet flexibeler.

[Gerco]

bodiam schreef op maandag 19 december 2005 @ 13:58:
Het voegt niets toe. Zodra je extra informatie gaat meesturen zullen applicaties die hiermee omgaan ook aangepast moeten worden. Ik vind dit dus niet flexibeler.

Maar applicaties die wel met de oude, maar niet met de nieuwe data willen werken moeten in jouw geval ook aangepast worden en in het flexibelere geval niet.

Het lijkt me niet zo'n probleem om er nog even een <forum> tagje omheen te zetten als de data van een forum afkomstig is, misschien wil je later ook nog je ledenlijst erbij gaan zetten, dan kun je dus in <forum> gewoon een tagje <members> toevoegen en kun je apps die de ledenlijst niet nodig hebben dus gewoon zo laten.

[Erkens]

bodiam schreef op maandag 19 december 2005 @ 13:58:
Het voegt niets toe. Zodra je extra informatie gaat meesturen zullen applicaties die hiermee omgaan ook aangepast moeten worden. Ik vind dit dus niet flexibeler.

Het voegt zeker wel wat toe: "wat het is" => een topic in een forum, het had namelijk ook een topic van bijvoorbeeld een mail coversatie kunnen zijn of weet ik veel wat je applicatie allemaal zou kunnen doen.

Ehm, juist door deze structuur aan te houden blijf je ten alle tijden backwards compatible op het moment dat je extra info toevoegd zoals Gerco al opmerkt hierboven.
In jouw geval zal ik als ik bijvoorbeeld die ledenlijst later mee wil sturen dan of een nieuwe extra XML moeten gebruiken en/of alle code herschrijven welke gebruik maakt van die XML.

Zelf zorg ik er altijd voor dat de XML's die ik maak overal gebruikt kunnen worden, dit kan je alleen zo doen als je van te voren goed nadenkt over wat je nu precies wilt versturen en waarom. En dan duidelijke regels/richtlijnen opstellen waarmee je eventueel zelfs je XML kan valideren.

[bodiam]

Gerco schreef op maandag 19 december 2005 @ 14:21:
[...]

Maar applicaties die wel met de oude, maar niet met de nieuwe data willen werken moeten in jouw geval ook aangepast worden en in het flexibelere geval niet.

Het lijkt me niet zo'n probleem om er nog even een <forum> tagje omheen te zetten als de data van een forum afkomstig is, misschien wil je later ook nog je ledenlijst erbij gaan zetten, dan kun je dus in <forum> gewoon een tagje <members> toevoegen en kun je apps die de ledenlijst niet nodig hebben dus gewoon zo laten.

Lijkt me ook geen probleem. Als je dan toch bezig bent, misschien kun je er ook ff een tag 'forums' (fora) bij zetten, want wie weet komen er wel meerdere forums. Misschien ook niet.

Ehm, juist door deze structuur aan te houden blijf je ten alle tijden backwards compatible op het moment dat je extra info toevoegd zoals Gerco al opmerkt hierboven.
In jouw geval zal ik als ik bijvoorbeeld die ledenlijst later mee wil sturen dan of een nieuwe extra XML moeten gebruiken en/of alle code herschrijven welke gebruik maakt van die XML.

Zeker niet. Je kunt niet in de toekomst kijken. Als jij een aanpassing gaat doen aan de huidige structuur, door bijvoorbeeld een <processThisForum>true|false</processThisForum> toe te voegen aan het forum element, zal 'oude' software echt niet plotseling backwards compatibel zijn. Het is gewoon niet nuttig om dingen toe te voegen aan een applicatie die toch niets toevoegen. Vooral omdat deze dingen vaak niet gebruikt worden (das mijn ervaring) of vaak discussies ( ) opleveren die tijd kosten. Dus pak gewoon wat je nodig hebt, en ga je in een nieuwe versie toch daar iets mee doen, verander het dan.

[ Voor 8% gewijzigd door bodiam op 19-12-2005 16:08 ]

[Erkens]

bodiam schreef op maandag 19 december 2005 @ 15:59:
Zeker niet. Je kunt niet in de toekomst kijken. Als jij een aanpassing gaat doen aan de huidige structuur, door bijvoorbeeld een <processThisForum>true|false</processThisForum> toe te voegen aan het forum element, zal 'oude' software echt niet plotseling backwards compatibel zijn. Het is gewoon niet nuttig om dingen toe te voegen aan een applicatie die toch niets toevoegen. Vooral omdat deze dingen vaak niet gebruikt worden (das mijn ervaring) of vaak discussies ( ) opleveren die tijd kosten. Dus pak gewoon wat je nodig hebt, en ga je in een nieuwe versie toch daar iets mee doen, verander het dan.

Jij bedoeld forward compatible, dat lukt idd bijna nooit nee
Maar als jij liever veel extra werkt wilt gaan doen, ga je gang, ik hou je niet tegen hoor
Het is alleen niet verstandig om verschillende structuren te gaan gebruiken die je bij elke uitbreiding weer moet aanpassen + bijbehorende code.

[bodiam]

Erkens schreef op maandag 19 december 2005 @ 16:03:
[...]

Jij bedoeld forward compatible, dat lukt idd bijna nooit nee

Okay, my mistake

Maar als jij liever veel extra werkt wilt gaan doen, ga je gang, ik hou je niet tegen hoor
Het is alleen niet verstandig om verschillende structuren te gaan gebruiken die je bij elke uitbreiding weer moet aanpassen + bijbehorende code.

Nouja, das juist de vraag he? Jij denkt dat dit minder werk is, omdat eventueel in de toekomst dit handig kan zijn. Ik denk dat dit meer werk is, omdat je er meer voor moet doen en het (nu) toch niet nodig hebt.
Wijzigigen aan structuren zijn veelal toch niet te voorspellen, dus waarom er nu al rekening mee houden? Je zult bij elke wijziging toch wel een deel van je code moeten aanpassen, dit soort aanpassingen houden dat niet tegen. Je legt echter een nutteloze structuur op. En als je vindt dat het niet nutteloos is en een functie vertegenwoordigt, stop het er dan vooral in. Maar dat doet het nu niet

[Verwijderd]

Erkens schreef op maandag 19 december 2005 @ 16:03:
Jij bedoeld forward compatible, dat lukt idd bijna nooit nee
Maar als jij liever veel extra werkt wilt gaan doen, ga je gang, ik hou je niet tegen hoor
Het is alleen niet verstandig om verschillende structuren te gaan gebruiken die je bij elke uitbreiding weer moet aanpassen + bijbehorende code.

Het is in grote lijnen juist wel verstandig wat Bodiam suggerreert. Je teveel bezig houden met wat eventueel komen gaat levert enkel redundante specificaties. Zorg liever dat wat je wilt laten zien correct geimplementeerd is. Het is daarom ook geen wonder dat de meeste specificaties beginnen met een of andere versie aanduiding. Aan de hand van de versie kun je wel de juiste manier van parsen ontdekken. Dus nu al tags verzinnen voor de toekomst is compleet zinloos. Je maakt het jezelf (nu en in de toekomst) alleen maar moeilijker.

[Erkens]

bodiam schreef op maandag 19 december 2005 @ 16:16:
Ik denk dat dit meer werk is, omdat je er meer voor moet doen en het (nu) toch niet nodig hebt.

En hoeveel is dat meerwerk? alleen maar het parsen van 1 extra (container) node.

Wijzigigen aan structuren zijn veelal toch niet te voorspellen, dus waarom er nu al rekening mee houden? Je zult bij elke wijziging toch wel een deel van je code moeten aanpassen, dit soort aanpassingen houden dat niet tegen.

Als je iedere keer je structuur moet wijzigen blijkt dat je er niet goed over hebt nagedacht

Je legt echter een nutteloze structuur op. En als je vindt dat het niet nutteloos is en een functie vertegenwoordigt, stop het er dan vooral in. Maar dat doet het nu niet

ehm, jij vindt die nutteloos. Jij houdt blijkbaar niet van structuur. Om weer dat voorbeeld van het forum aan te halen. Een topic, waar is dat onderdeel van? Juist een forum. Een forum _kan_ ook eigenschappen hebben welke je er op dit moment nog niet in wilt, maar wellicht bij een volgende release wel. Leuk en aardig, maar we gaan echt niet meer werk ervan maken, en geven alleen maar die topic tags in de XML.
Bij de volgende release heb je weer een nieuwe XML structuur. Hierbij moeten vervolgens alle applicaties worden aangepast die daarvan gebruik maken. Ook applicaties die bijvoorbeeld niet door jou geschreven zijn.
Een goed voorbeeld is hier op dit forum te zien. De XML die je kan gebruiken heeft een redelijk duidelijke structuur waarin je enorm flexibel bent.

[bodiam]

Erkens schreef op maandag 19 december 2005 @ 16:29:
En hoeveel is dat meerwerk? alleen maar het parsen van 1 extra (container) node.

In dit geval niet veel meer werk. Maar dit is echt niet de enige plek in de structuur van een applicatie waarin dit gebeurt. Extra abstractielaag hier, eentje daar, ohja, stel dat in de toekomst gebruikers meerdere accounts mogen hebben, etc. Ik probeer het hier iets breder te trekken dan de TS in zijn voorbeeld voorstelt.

Als je iedere keer je structuur moet wijzigen blijkt dat je er niet goed over hebt nagedacht

Mee eens . Maar van een wijziging moet je ook geen drama maken. Als je structuur maar zo is opgezet dat wijzigingen niet veel pijn kosten.

ehm, jij vindt die nutteloos.

"Wat is nou beter? Consequent mijn structuur (schema?) aan blijven houden? terwijl de forum tags (en evt diepere niveau's) vrijwel nutteloos zijn?"

Nee, de TS vind het nutteloos. Uit deze text haal ik in ieder geval niet dat ze enig nut dienen, anders was deze discussie totaal overbodig geweest. Wellicht dat ze in de toekomst iets gaan voorstellen, misschien ook niet.

Jij houdt blijkbaar niet van structuur.

Dat zijn jouw woorden. Vond zelf dat ik altijd wel redelijk gestructureerd werk, maar je kent me na 1 middag misschien beter dan ik mezelf na 25 jaar.

Om weer dat voorbeeld van het forum aan te halen. Een topic, waar is dat onderdeel van? Juist een forum. Een forum _kan_ ook eigenschappen hebben welke je er op dit moment nog niet in wilt, maar wellicht bij een volgende release wel. Leuk en aardig, maar we gaan echt niet meer werk ervan maken, en geven alleen maar die topic tags in de XML.
Bij de volgende release heb je weer een nieuwe XML structuur. Hierbij moeten vervolgens alle applicaties worden aangepast die daarvan gebruik maken. Ook applicaties die bijvoorbeeld niet door jou geschreven zijn.

Klopt. Jammer. Misschien dat (zoals ik eerder al zei) een forum wel hoort onder forums. Who knows? En misschien bestaan topics wel uit groups? moet je ook meteen een 'group' element tussen forum en topic gaan hangen?

Wat voor de 1 misschien vanzelfsprekend is, is voor de ander niet. Zoals ik eerder zei: je kunt wel rekening gaan houden met de toekomst, maar hoe weet je nou wat in de toekomst de eisen zullen zijn? Doe gewoon wat de eisen zijn, en zorg dat de structuur zo opgezet is dat het aanpasbaar is. Komen er meerdere versies? Zorg dan voor een versienummer. Komt er een andere structuur? Zorg dan dat de structuur niet keihard vastligt in je code. Dat zorgt voor flexibele structuren, en daarvoor heb je echt nu nog geen extra voorzieningen voor nodig in je XML.

(wat een discussie over een stukje XML btw :-))