[XSD/XML Schema] Conditionele MinOccurs?

[RobIII]

Ik ben bezig met een (aangeleverde) XSD ietwat te verbouwen. We krijgen de XSD voorgeschreven door een derde partij, en ik wil daar eigenlijk zo weinig mogelijk aan veranderen om de integratie te bespoedigen (hoe meer ik aanpas, hoe meer zij in hun software moeten aanpassen, hoe langer het duurt). Ik heb nu de mogelijkheid van hun dus gekregen de XSD te corrigeren waar ik dat nodig vind.

De XSD is eigenlijk helemaal goed zoals 'ie is, er waren maar een paar kleinigheidjes die ik opgelost wilde hebben. Het relevante gedeelte van de "code":

code:

<xs:element name="VervoerStroom">
    <xs:complexType>
        <xs:choice>
            ...
            <xs:element name="Binnenland">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="Bestemming" minOccurs="0">
                            <xs:complexType>
                                <xs:choice>
                                    ....
                                </xs:choice>
                            </xs:complexType>
                        </xs:element>
                        <xs:element name="Herkomst" minOccurs="0">
                            <xs:complexType>
                                <xs:choice>
                                    ....
                                </xs:choice>
                            </xs:complexType>
                        </xs:element>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
        </xs:choice>
    </xs:complexType>
</xs:element>

En even voor de beeldvorming:


Mijn vraag is eigenlijk simpel: Ik heb de XSD dusdanig gewijzigd zodat bij een Import de Bestemming optioneel wordt (minoccurs=0). Bij een Export is de Herkomst optioneel (minoccurs=0). Deze waren eerst "verplicht". Bij de Binnenland meldingen is het echter nét anders. Hier bij is altijd minimaal 1 van de elementen verplicht (dus of een bestemming, of een herkomst) en is het toegestaan om ze allebei (dus bestemming én herkomst) op te nemen.

Nu zou je deze "minoccurs" dus eigenlijk conditioneel moeten kunnen maken op de een of andere manier, of misschien (maar dat zie ik ook zo snel niet) een hele vage constructie met allerlei "tussen-elementen" moeten maken. Maar zoals ik al aangaf wil ik het liefst zo min mogelijk aanpassen om het voor de andere partij zo makkelijk mogelijk te maken de wijzigingen door te voeren. Iemand enig idee hoe ik dit het best aan kan passen? Zoals ik het nu heb (minoccurs=0 voor beide elementen) zou een "Binnenland" melding zonder herkomst en bestemming dus valid zijn. Dat zal me overigens persoonlijk worst wezen, want dat soort dingen zou ik zelf gewoon in de software vangen. Ik wil de andere partij daar echter niet mee opzadelen als het niet nodig is en liever zorgen dat de XSD precies doet wat ze willen.

Ik kon op Google niet veel zinnigs vinden (veel mensen met dezelfde vraag, zelden antwoord en alle "antwoorden" waren dat "het niet kan"). Ik vrees zelf helaas ook dat het niet kan, maar ik wil het graag even bevestigd horen

offtopic:
Als ik de XSD van de grond af had mogen bouwen had het er sowieso heel anders uit gezien, maar dat is dus in dit geval niet aan mij helaas

[ Voor 35% gewijzigd door RobIII op 12-10-2005 14:47 ]

[RobIII]

Hebben jullie dat nou ook dat als je iets post je meteen daarna zelf de oplossing bedenkt?

code:

<xs:element name="VervoerStroom">
    <xs:complexType>
        <xs:choice>
            ...
            <xs:element name="Binnenland">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="Bestemming">
                            <xs:complexType>
                                <xs:choice>
                                    ...
                                </xs:choice>
                            </xs:complexType>
                        </xs:element>
                        <xs:element name="Herkomst" minOccurs="0">
                            <xs:complexType>
                                <xs:choice>
                                    ...
                                </xs:choice>
                            </xs:complexType>
                        </xs:element>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
            <xs:element name="Binnenland">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="Bestemming" minOccurs="0">
                            <xs:complexType>
                                <xs:choice>
                                    ...
                                </xs:choice>
                            </xs:complexType>
                        </xs:element>
                        <xs:element name="Herkomst">
                            <xs:complexType>
                                <xs:choice>
                                    ...
                                </xs:choice>
                            </xs:complexType>
                        </xs:element>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
        </xs:choice>
    </xs:complexType>
</xs:element>

/Edit:
Damned!
Dat gaat dus niet werken... Of wel? De theorie achter dit idee was eigenlijk dat het Binnenland element altijd 1 van de twee verplichtte (Bestemming/Herkomst), en eventueel een 2e toestond. Door "Binnenland" 2x te definiëren dacht ik het schema voor het lapje te kunnen houden, maar dat gaat dus niet

[ Voor 211% gewijzigd door RobIII op 12-10-2005 14:27 ]

[Infinitive]

Als je een conditionele min-occurs zou willen specificeren in XML schema afhankelijk van de input dat je leest, dan zou de grammatica die XML schema beschrijft context-sensitive worden. En dat kan je met XML niet parsen

Maar kan je de set van non-terminals voor binnenland en buitenland disjoint maken? Dus dan heb je BinnenlandExport, BinnenlandImport, BuitenlandExport, BuitenlandImport, BinnenlandExportHerkomst,... etc. Als ik je vraagstelling goed begrepen hebt, kan je nu wel de min-occurs correct instellen.

Helaas wel een explosie van het aantal nonterminals

[ Voor 38% gewijzigd door Infinitive op 12-10-2005 15:09 ]

[RobIII]

Infinitive schreef op woensdag 12 oktober 2005 @ 15:04:
Als je een conditionele min-occurs zou willen specificeren in XML schema, dan zou de grammatica die XML schema beschrijft context-sensitive worden. En dat kan je met XML niet parsen

Uh, ja. Zit wat in. Toch kom ik wel methodes tegen (zoals RELAX(?)) die het wel schijnen te kunnen
(Moet eerlijk bekennen dat, hoewel ik wel eens wat stoei met dit soort dingen, ik nog niet echt diepgaande kennis heb van XSD's etc hoewel ze relatief goed te volgen zijn voor een devver als je het idee erachter begrijpt.

Infinitive schreef op woensdag 12 oktober 2005 @ 15:04:
Maar kan je de set van non-terminals voor export en import disjoint maken? Dus je hebt een ExportBestemming en een ExportHerkomst en een ImportBestemming en een ImportHerkomst?

Dat zou wel een idee zijn, maar dan zie ik even niet concreet hoe dat precies zou uit komen zien... Ik zou dan eigenlijk een BinnenlandA en BinnenlandB krijgen om het zo maar even te zeggen? Dus in mijn "oplossing" de Binnenland elementen (die dus dubbel voorkomen) hernoemen naar A en B? (uiteraard bedoel ik met A en B Import/Export)

[ Voor 43% gewijzigd door RobIII op 12-10-2005 15:14 ]

[Infinitive]

Lees mij post nogmaals. Heb het een en ander in de tussentijd geedit

[RobIII]

Infinitive schreef op woensdag 12 oktober 2005 @ 15:04:
Als ik je vraagstelling goed begrepen hebt, kan je nu wel de min-occurs correct instellen.

Als ik je post goed begrepen heb wel ja

Infinitive schreef op woensdag 12 oktober 2005 @ 15:04:
Helaas wel een explosie van het aantal nonterminals

Ja, daar was ik al bang voor zoals ik aangaf in mijn topicstart En dat probeer ik nou juist te vermijden...

[ Voor 102% gewijzigd door RobIII op 12-10-2005 15:23 ]

[Infinitive]

Je zou natuurlijk naderhand via een transformatie je XML structuur kunnen vereenvoudigen. Je hebt dan tenslotte de check aan de hand van het complexere schema al gedaan.

[mbravenboer]

Infinitive schopte me naar dit topic, waarvoor ik hem even wil bedanken, want dat geeft me de kans om even lekker te flamen! Ik moest wel even heel hard graven in m'n geheugen, want ik heb dit al jaren niet meer gedaan.

Wat jij hier wilt, kan je helaas niet uitdrukken in W3C XML Schema. Dit is formeel onderbouwd in het artikel "Taxonomy of XML Schema Languages using Formal Language Theory" (ff googlen als je het wilt lezen). W3C XML Schema valt in de categorie "Single-type Tree Grammars". In jouw geval zijn de drie verschillende binnenlanden (1-0, 0-1,1-1) "competing", wat niet toegestaan is in W3C XML Schema. Ik hoop dat ik deze situatie goed herkend heb, want het is lang geleden dat ik hiermee bezig geweest ben.

RELAX NG support alle tree grammars en daarom kan je dit dus wel in RELAX NG uitdrukken. Voorbeeldje:

code:

grammar {
  start =
    binnenland

  binnenland =
    element Binnenland {
        (herkomst?, bestemming)
      | (herkomst,  bestemming?)
    }

  herkomst =
    element Herkomst {text}

  bestemming =
    element Bestemming {text}
}

W3C XML Schema vermijd ik zoveel mogelijk. Persoonlijk, zou ik me niet druk maken om dat W3C XML Schema van die derde partij en je XML met een eigen schema valideren. Niemand verplicht om je altijd hetzelfde schema te gebruiken: 1 van de betere ideeen rond XML schema talen is zelfs dat je eigenlijk het liefste verschillende schema's zou willen gebruiken op hetzelfde XML document. Je kan in dit geval dan gewoon een schema maken in een beschaafde schema taal, dat wil zeggen: RELAX NG.

Alle tijd die in W3C XML Schema gestoken wordt vind ik verspeelde tijd. W3C XML Schema is rijp voor de schroothoop. Het is een draak van een taal en je kan er eigenlijk ook maar bar weinig in uitdrukken. Steeds meer verstandige mensen zie je W3C XML Schema de rug toe keren. Erik Meijer (Microsoft) kan hier bijvoorbeeld vol overgave over vertellen. W3C XML Schema is zeer lastig compleet te implementeren in een data-binding of validatie tool, wat het bijvoorbaat al een kansloze taal maakt.

Ok, de flame is nu wel duidelijk denk ik .

Een aantrekkelijk, lichtgewicht, alternatief is overigens nog om Schematron te gebruiken. In Schematron kan je verzamelingen van regels definieren die je normaal gesproken niet in een XML schema taal kan of wil uitdrukken. Het zou dus een optie kunnen zijn om op het algemenere W3C XML Schema te werken en dan een set van aanvullende Schematron regels te gebruiken. Je kan zelfs de Schematron regels opnemen in het W3C XML Schema bestand.

RELAX NG in combinatie met Schematron is wat mij betreft de moeite waard om te leren en tijd in te investeren. Ze worden/zijn door OASIS en ISO gestandaardiseerd, dus het is ook iets waar je op kan vertrouwen voor de toekomst.

(merk op dat ik altijd W3C XML Schema zeg: "XML schema taal" is een algemene term, waaronder bijvoorbeeld DTD, W3C XML Schema en RELAX NG vallen. Het is erg ongelukkig dat het W3C de term XML Schema geclaimt heeft.)

[ Voor 3% gewijzigd door mbravenboer op 12-10-2005 21:16 ]

[RobIII]

mbravenboer schreef op woensdag 12 oktober 2005 @ 21:03:
W3C XML Schema vermijd ik zoveel mogelijk. Persoonlijk, zou ik me niet druk maken om dat W3C XML Schema van die derde partij en je XML met een eigen schema valideren.

Dank voor je uitgebreide reactie
Ik ga er morgen even verder op in (werk != prive ) maar ik kan wel vast zeggen dat het schema voor mij zowieso niet interessant is. Ik poep de XML gewoon "vast" uit en valideer helemaal niks. De derde partij valideert het en duwt het door naar een zoveelste partij. Natuurlijk valideer ik het ook even tegen dat schema, zodat ik het niet terug krijg, maar dat is voor mij in principe helemaal niet interessant. De andere partij heeft geen kennis van zaken over de inhoud van het bericht en de 'regeltjes' die daar bij horen en kwam dus met het huidige XSD voorstel. Daar mag ik nu dus commentaar op leveren (nadat ze maaaanden aan die XSD hebben "gewerkt") en suggesties in maken. Om dit te bespoedigen wring ik mezelf wel in wat bochten om het maar gewoon via hun XSD definitie te maken. Helaas kan ik dan niet alles kwijt (of ik moet het gaan vullen met dummy waardes) zoals ik het wil. Dat vereist voor hen de minste aanpassingen (=dus het snelste).

Morgen meer

/edit: Zal maar niet schoppen
Ik heb even gekeken naar het Schematron en RELAX NG gebeuren, en ik moet zeggen dat het interessant genoeg uit ziet om me eens in te verdiepen. Helaas heb ik daar nu niet de gelegenheid voor en zal ik dus kiezen om gewoon de beide elementen (Bestemming/Herkomst) gewoon een minoccurs van 0 te geven. Dat is de enige manier om straks voor mij valid documenten aan te leveren zonder met ranzige dummy waardes te gaan werken of zonder de andere partij op te zadelen met allerlei nieuwe technologieën. Ik weet dat het niet mijn probleem is, maar het is wel mijn zaak om er voor te zorgen dat dit project zo snel mogelijk in productie kan worden genomen. Ga ik aandringen op teveel wijzigingen dan vertraag ik het project dusdanig dat het waarschijnlijk pas tegen sint Juttemis klaar is. Als ik bekijk met hoeveel horten en stoten en moeite de initiële XSD is gemaakt, en hoe lang daar over is gedaan, durf ik het risico niet te nemen om de heren nu een radicaal ander voorstel te doen. 80% van de documenten die bij hen aangeleverd worden zullen toch van ons afkomstig zijn, en als ik er even bij waarschuw dat ze in hun software even moeten kijken of de Binnenland node niet leeg is lijkt me dat makkelijker voor hen te implementeren dan voorgestelde.

Nogmaals, hulde voor jullie reacties. Ik heb er veel van geleerd en zal er veel aan hebben in de toekomst denk ik. Helaas ben ik zelf nog niet echt een guru op dit gebied en zal ik, ook vanwege die reden, moeten gaan voor de weg met de minste weerstand. Het is niet anders

[ Voor 39% gewijzigd door RobIII op 13-10-2005 10:57 ]