[XML/Schema] guideline abstract type

[Alarmnummer]

Op dit moment maak ik in mijn schema bestanden geen anonieme types.

dus:

code:

<xsd:complexType name="persoonType">
   <xsd:sequence>
     <xsd:element name="naam" type="xsd:string" />
     <xsd:element name="adres" type="adresType" />
   </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="adresType">
   <xsd:sequence>
     <xsd:element name="woonplaats" type="xsd:string"/> 
     <xsd:element name="adres" type="xsd:string"/>
   </xsd:sequence>
</xsd:complexType>

ipv

code:

<xsd:complexType name="persoonType">
   <xsd:sequence>
     <xsd:element name="naam" type="xsd:string" />
     <xsd:element name="adres">
        <xsd:complexType>
         <xsd:sequence>
            <xsd:element name="woonplaats" type="xsd:string"/> 
            <xsd:element name="adres" type="xsd:string"/>
         </xsd:sequence>
         </xsd:complexType>      
     </xsd:element>
   </xsd:sequence>
</xsd:complexType>

Het voordeel van niet anonieme types is dat wat overzichtelijker blijft. Het nadeel is dat er dus veel types onstaan die je eigelijk toch niet gaat hergebruiken.

Mijn vraag is wat de guideline voor het een of het ander is.

ps: ik heb minOccurs en macOccurs er niet bijgezet zodat het beetje overzichtelijk blijft.

ps2:het topic moet heten:[XML/Schema] guideline anonieme types.

[Verwijderd]

Als je het type niet hergebruikt, gewoon Abstract maken. Wat heb je aan een beetje met een naam, als dat naampje niet voor gaat komen verder?
Het Abstract maken van niet hergebruikte types wordt op de lange duur overzichtelijker dan het uitschrijven van typenamen, omdat je zoals je zelf al zegt wel erg veel typedeclaraties gaat krijgen.

[Alarmnummer]

Op woensdag 13 maart 2002 13:32 schreef Hieronymus het volgende:
Als je het type niet hergebruikt, gewoon Abstract maken. Wat heb je aan een beetje met een naam, als dat naampje niet voor gaat komen verder?
Het Abstract maken van niet hergebruikte types wordt op de lange duur overzichtelijker dan het uitschrijven van typenamen, omdat je zoals je zelf al zegt wel erg veel typedeclaraties gaat krijgen.

Ik neem aan dat je anoniem bedoelt en jij zit dus ook in twijfel. Ik vind het lastig om soms duidelijke type namen te bedenken die eigelijk in 1 bepaalde context interessant zijn. Je zou dan eventueel als naam voor adresType kunnen kiezen:
name="persoonType:adresType" zodat je laat zien dat adresType bij persoonType hoort en zodoende geen last krijgt van lastige namen (vooral als je verderop nog een keer een adres type moet maken mbv daarin het extra veld 'land'). Je zou ook eventueel een nieuwe namespace kunnen aanmaken.

[Verwijderd]

Idd, ik bedoelde natuurlijk Anoniem, ik zat nog even teveel in mijn UML (was een opdracht aan het maken).
Ik zit niet zozeer in dubio, alswel dat ik zou zeggen als het niet hergebruikt wordt, geef het geen naam.
De guideline zou ik niet weten. Er wordt nog dagelijks geklusd aan XMLSchema.

Ik zou zeggen blijf goed naar de W3C recommendations kijken! Het is in ieder geval al een stuk beter dan DDF

[Alarmnummer]

Op woensdag 13 maart 2002 16:11 schreef Hieronymus het volgende:
Ik zou zeggen blijf goed naar de W3C recommendations kijken! Het is in ieder geval al een stuk beter dan DDF

bedoel je misschien DTD?

[Verwijderd]

Damn... Ik was vanmiddag echt met andere dingen bezig...
DDF = Data Definition File, komt uit BTrieve tijd
DTD is idd wat ik bedoelde....

[Alarmnummer]

DLL,DDL,DDT,DTD wat moet je er allemaal mee *had volgens mij dichter moeten worden*

[Alarmnummer]

Ik schop hem nog even naar boven want ik heb nog geen antwoord op mijn vraag..

[Verwijderd]

Ik denk niet dat erg veel mensen zich er al mee bezighouden hiero. Ik heb laatst gelukkig wat XMLSchema in een college zien terug komen en ook wat discussie erover gevoerd, vandaar dat ik wel een kleine suggestie had.

[mbravenboer]

Tja ik had niet zoveel trek om weer allerlei guidelines voor te gaan stellen dus wilde eerst niet reageren . Zal dat dan toch maar ff doen: maar er komen geen guidelines .

Het valt mij op dat je erg vaak topics opent over guidelines, regels of richtlijnen. Dat vind ik aan de ene kant een goed signaal, want het geeft duidelijk aan dat je nadenkt over de stuff waarmee je bezig bent. Je wilt graag perfecte oplossingen en gelukkig verkeer je niet in de waangedachte dat je die altijd zelf wel op kunt stellen. Het is een goed idee om rond te kijken wat andere mensen hier al over gefilosofeerd en wellicht zelfs opgesteld hebben.

Helaas blijft het toch een feit dat het design van schema's, net als het ontwerpen van een OO applicatie een creatief proces is wat simpelweg niet aan zeer strikte regels voldoet. Als dit wel zo zou zijn, zou dat best vervelend zijn want dan zijn er geen betere en iets minder betere programmeurs zijn en zou ons vak een stuk minder boeiend zijn .

In de meeste gevallen zullen guidelines beperkt blijven tot enkele zeer globale hints die typische situaties beschrijven...

In dit geval denk ik dat je bij het ontwerp van een XML Schema eens goed moed bedenken wat je aan het doen bent en hoe je dit in een Java design oplost. In Java zal je af en toe klassen package-protected maken omdat je weet dat deze nooit ergens gebruikt zullen worden omdat ze te specifiek zijn voor een bepaalde situaie. Anders klassen maak je bewust wel publiek omdat je op je klompen kan aanvoelen dat deze nuttig zijn of zelfs elders gebruikt moeten worden. Bij het ontwerp van een XML Schema werkt dit in feite hetzelfde: als je alles maar 'publiek' zou maken met een eigen type wek je wellicht snel de illusie op dat dit type een belangrijke, hergebruikte rol speelt in je schema. Als dit voor bepaalde typen niet het geval is, zou ik er geen apart type van maken. Ditzelfde zie je overigens ook terug in het ontwerpen van abstract-syntax-trees, waar je zelf ook al ervaring mee hebt.

Als je echt een diepgaande discussie wilt met mensen die meer met XML Schema's bezig zijn (ik doe er niet zoveel mee) kan je de moeite nemen om je op de xml-dev mailing list aan te melden en een leuke vraag inelkaar te breien. Je zult dan waarschijnlijk erg veel medewerking krijgen: ze geilen daar werkelijk op alle mogelijke discussies .

Heb je overigens al eens naar RELAX NG gekeken? Dit wordt getipt als een de sluipmoordernaar a la SAX van 2002 .

[Alarmnummer]

Dan zal ik mijn guideline topic maar niet gaan openen: wanneer inner classes gebruiken?

En ik ben ook voor het creatieve denk proces. Alleen loopt je nu tegen vaak voorkomende problemen aan die ik graag 'netjes' wil oplossen. In java heb je op veel gebieden guidelines. Bv over gebruik runtime/checked exception. Het is geen probleem om het ander te kiezen *ahum* maar het is niet 'de norm'. En als ik dan een antwoord krijg voor de keuze kan ik me weer bezig houden met de echt interessante dingen.

Ik heb trouwens dat RELAX NG nog steeds niet bekeken. Dus ik kan er nog niets over zeggen. Ik vind intussen die schema`s wel lekker werken (beter dan dtd`s). En dan kan ik weer iets nieuws leren Maar als jij er zo positief over bent dan zal er wel een goeie reden voor zijn.

[Goodielover]

Wat mij betreft zijn overzichtelijkheid en hergebruik allebei argumenten om al dan niet anoniem te maken.
Al te grote definities leiden tot problemen bij het begrijpen/analyseren en kennis overdracht rond je systeem.

Daarnaast kan ik me ook vanuit een design oogpunt de mate van onderkenning in je systeem van het samengestelde type als beslissingscriterium voorstellen.
Als jij in de systeem het bij een persoon echt over z'n adres (als object) hebt zou ik er hier ook een apart type van maken.
Het blijft een leuk vak dat ontwerpen/programmeren.

[Alarmnummer]

Met dat adres was een voorbeeldje Ik heb een scherma herschreven met zoveel mogelijk anonieme classes (dus waar hergebruik niet nodig is, een anoniem type maken) en naarmate ze dieper genest zijn, had ik meer moeite om te begrijpen waar ik was. Ik denk dat een nesting tot max 3 nog efficient is en daarna begint het echt een brei te worden.

ps: naarmate ik langer met XML bezig ben vind ik het steeds geweldiger te vinden. XML is echt fantastisch.