[Bitrepository-devel] versionering af xsd'ere

Wed May 11 09:40:40 CEST 2011

Hej Kåre

Godt med casene, de bør nok komme med i en beskrivelse også.

Ideen med minVersion var at åbne mulighed for at opdateringer af protokol uden at det nødvendigvis behøver at ske for alle på samme tid, hvilket ville blive en flaskehals for mange små ændringer. 

Ideen var at version går på operation - dvs. det går i princippet IKKE på de enkelte messages.

Jeg vil lige se på anden vinkel også, nemlig typen af de ændringer der kan komme. En ændring vil kunne brydes ned til bygge klodser af følgende:
1. Tilføjet felt
2. Fjernet felt
3. Ændret felt

Ad 1:
Hvis vi antager at der er tilføjet et felt til Request del, som udvider mulighederne for at spørge (for eksempel patters for ID'er), så er scenariet som følger:
- i identify Pillars/contributers delen vil der komme Response som har Pillars/contributers versionsangivelse. Dvs. Hvis det ekstra felt er i version 3 og pillar kun har version 2, så vil pillar fejle på det ekstra felt, hvis der spørges på det. Al anden kommunikation går godt. Tilsvarende for Reponse delen, så bør der ikke svares med en højere version end det der forespørges på.
Denne er eksempel på din case 1 og 2.

Der kan selvfølgelig være tilføjelse af felter som har helt speciel betydning for funktionaliteten, hvor der er behov for at opdatere alle komponenter samtidigt. Dette vil være et tilfælde for din case 3

Ad 2:
Såfremt vi ikke snakkker om et felt med signifikant betydning, såsom SlaID, så vil dette vil "kun" være et spørgsmål om at sikre bagudkompatibilitet. Jeg tror nu ikke dette er hyppigt forekommende tilfælde, og det kan vælges at betragtes som en ændring (se nedenfor).

Ad 3:
Hvis typen er ændret for et bestemt felt, så kan der være tale om en ændring der rent faktisk kræver at alle komponenter opdateres før systemet kan køre videre. For eksempel hvis SlaID typen ændres.
Dette er tilfældet for din case 3 (hvis komponent med lavere version stadig eksistere/startes i systemet)

Er dette en hjælp? Giver det mening?

Mvh. Eld

-----Oprindelig meddelelse-----
Fra: Kåre Fiedler Christiansen [mailto:kfc at statsbiblioteket.dk] 
Sendt: 10. maj 2011 20:45
Til: Eld Zierau; bitrepository-devel at ml.sbforge.org
Emne: SV: versionering af xsd'ere

Hejsa,

Jeg har ikke fået svaret på denne mail, og heller ikke ringet.

Jeg håber at nå at ringe i løbet af torsdag.

Et af de problemer jeg identificerede var netop det er er beskrevet i punkt 3 nedenfor, nemlig hvem der står for at sætte værdien af "version" og "minVersion" og hvor får de værdierne fra? Det er ikke spor tydeligt for mig. og som minimum skal det være velbeskrevet nok, til at ben-implementører kan udfylde dem korrekt.

Desuden har jeg problemer med at forstå den forventede semantik af attributterne. Jeg prøver her at skrive min forståelse. Hvis den er korrekt kan jeg skrive den ind på protokolsiderne.

Eksempel:
A benytter skemaer af version 2
B benytter skemaer af version 3

Case 1
A sender besked X med version="2" minVersion="2"
Resultat: B forstår beskeden og svarer. Korrolar: Vi forventer at alle spillere forstår alle beskeder af ældre versioner. Altså: beskeden med version 2 er gyldig efter skemaet i version 3.

Case 2
B sender besked Y med version="3" minVersion="2"
Resultat: A forstår beskeden. Korrolar: Beskeden med version 3 er gyldig efter skemaet i version 2. Men hvorfor har den så et nyt versionsnummer?

Case 3
B sender besked Z med version="3" minVersion="3"
Resultat: A forstår ikke beskeden. Den melder en fejl.

Resultaterne af Case 1 og Case 2 bekymrer mig.

Case 1 kan jeg godt spise: Jeg tror vi aftalte at nye versioner kun tilføjer elementer. Dermed kan det lade sig gøre at implementere Case 1 relativt enkelt.

Case 2 derimod har jeg svært ved at få til at give mening. Umiddelbart er besked Y ugyldig efter skema 2, med mindre vi har defineret vores skema til at være åbent på det sted hvor skemaet er udvidet, og sådan ser vores skemaer i hvert fald ikke ud lige nu.
Specifikke instanser af beskeder fra skema 3 kan sagtens være gyldige efter skema 2, men det kræver at B er intelligent nok til at vide om beskeden er gyldig efter skema 2 eller ej.
En forståelse af hvordan det skulle virke kunne være at man skal ignorere ugyldige elementer, når man parser besked Y; og minVersion="2" betyder semantisk at det er sikkert at ignorere dem. Det er imidlertid ikke nødvendigvis enkelt at finde ud af hvad der skal ignoreres hvis skemaændringen er mere kompleks end tilføjelse eller fjernelse af et element - f.eks. blot at der er byttet om på to elementer. Og hvis det er det der er den forventede opførsel, kan vi slet ikke bruge et skema-baseret automatisk framework, som vi gør nu i vores java-implementation, om som jeg også har forstået .NET-løsningen bruger.

Desuden kan jeg kun finde på meget få eksempler hvor man udvider skemaet, men hvor det giver mening helt at ignorere udvidelsen. Umiddelbart kan jeg komme på eksempler som mere finkornet udvælgelse af data ved access operationer, eller krav om yderligere behandling ved modificerende operationer. I ingen a tilfældene virker det som acceptabelt helt at ignorere elementerne. Mikis kom op med et eksempel på, at man muligvis kunne ønske nogle flere oplysninger i et audit trail, men det ikke var essentielt hvis man ikke fik dem, så okay, der kan måske være tilfælde. Men i langt de fleste tilfælde virker det ilt at hvis man bruger skemaudvidelsen, så forventer man også at den bliver overholdt.

Jeg har derfor svært ved at finde ud af hvordan skemaversionering forventes at virke, og om løsningen virker i praksis.

Hilsen
  Kåre
--
Kaare Fiedler Christiansen - Software developer
THE STATE AND UNIVERSITY LIBRARY,
Universitetsparken 1, 8000 Aarhus C, Denmark.
Phone: +45 89462036
________________________________________
Fra: bitrepository-devel-bounces at ml.sbforge.org [bitrepository-devel-bounces at ml.sbforge.org] På vegne af Eld Zierau [elzi at kb.dk]
Sendt: 4. maj 2011 13:42
Til: bitrepository-devel at ml.sbforge.org
Emne: [Bitrepository-devel] versionering af xsd'ere

Hej Kåre

Så får du lige lidt på mail alligevel, så må vi se om telefonen skal yil hjælp også

Der er følgende udfordringer

1.     Da xsd'erne ligger i forskellige filer, og der ikke er omsluttende tag, så er skema versions begrænset mening i selve xsd'en

2.     Betydningen af schema versionen er tvetydig.

3.     Værdi af minVersion kan ikke specificeres i xsd'erne, så den skal ind på anden vis da den hører med

Ad 1:
Vi kan samle til en XSD med følgende f.eks. BitRepository.xsd
<xs:schema
  targetNamespace="http://bitrepository.org/BitRepository.xsd"
  attributeFormDefault="unqualified"
  elementFormDefault="qualified"

  xmlns="http://bitrepository.org/BitRepositoryData.xsd"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>

  <xs:import schemaLocation="xsd/BitRepositoryElements.xsd" namespace="http://bitrepository.org/BitRepositoryElements.xsd" />
  <xs:import schemaLocation="xsd/BitRepositoryData.xsd" namespace="http://bitrepository.org/BitRepositoryData.xsd" />
  <xs:import schemaLocation="xsd/BitRepositoryMessages.xsd" namespace="http://bitrepository.org/BitRepositoryMessages.xsd" />

  <xs:element name="Version">
    <xs:annotation><xs:documentation xml:lang="en">
    Schema version (1)
    </xs:documentation></xs:annotation>
  </xs:element>
</xs:schema>

Og så kan det diskuteres om det er et bitRep tag med version attribut, om vi definere værdi via konvention i schema eller om det ligges i xml ved siden af. Bemærk at denne ekstra xsd gør det nemmere for xmllint da denne kan køres med kommando
   xmllint --noout --schema ../../BitRepository.xsd *.xml
og behovet for at have eksempler I forskellige undermapper forsvinder.

Hvis man ser på METS, så har de under mapper for forskellige versioner og så er sidste nye version under hovedkataloget også, - jeg ved ikke om det kan bruges til noget.
  http://www.loc.gov/standards/mets/version19/mets.xsd = http://www.loc.gov/standards/mets/mets.xsd
  http://www.loc.gov/standards/mets/version18/mets.xsd
  http://www.loc.gov/standards/mets/version17/mets.xsd
  .

Ad 2.
Vores udgangspunkt var at schema version ikke skulle ændre sig, hvis det ikke var nødvendigt med ny kode for at bruge den. Dette er ikke tilfældet i det der er beskrevet ovenfor - her vil schema version ændre sig for alle ændringer. Spørgsmålet er så om der er tale om to forskellige former for skema versioner.

Ad 3.
Vi skal have en måde at definere minVersion sammen med skemaerne, evt. i separat xml som ligger sammen med skemaerne?

I det hele taget skal der tænkes meget nøje over hvordan kataloger med de forskellige xsd'er (og evt. xml'er) laves.

Mvh. Eld

[cid:image001.jpg at 01CC0A5E.8855CDF0]

Det Kongelige Bibliotek
Nationalbibliotek og Københavns Universitetsbibliotek

Eld Zierau
IT-konsulent | Digital Preservation Specialist

Det Kongelige Bibliotek | The Royal Library
Afdelingen for Digital Bevaring | Digital Preservation
P.O. Box 2149 | DK-1016 København K
tel +45 3347 4690 | Fax +45 3393 2218 | elzi at kb.dk<mailto:elzi at kb.dk> | www.kb.dk<http://www.kb.dk>

Besøgsadresse | Visiting address | Søren Kierkegaards Plads 1
Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 København K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42
IBAN DK2002164069032583 | Swiftcode DABADKKK