Kategoriat » JHS-suositukset » JHS 170 » Atomaaristen elementti- ja tyyppimääritysten esittely
Yhdistelmä näkymä Sisentämätön näkymä Puunäkymä
Aiheet [ Edellinen | Seuraava ]
Uusi aihe Uusi aihe
Atomaaristen elementti- ja tyyppimääritysten esittely
toggle
Atomaaristen elementti- ja tyyppimääritysten esittely
16.6.2009 8:37
Moi,

Olen työskennellyt JHS-170-suositusta hyödyntävän skeemakuvauksen kanssa ja havainnut seuraavan asian. Suosituksen kohdassa 8.2 sanotaan seuraavasti:


Pääsääntöisesti organisaation omissa skeemoissa PITÄISI viitata atomaariseen elementtimääritykseen. Atomaarisen määrittelyn muuttaminen organisaation tarpeita vastaavaksi on helpompaa viittaamalla vastaavaan tyyppimääritykseen. Tämän vuoksi organisaatio SAA omissa skeemoissaan viitata tyyppimääritykseen.


Eli tästä seuraa, että oikeanlainen(?) tapa rakentaa yksittäinen tyyppi olisi (esimerkeissä ei ole nimiavaruuksia tai importteja, oletusnimiavaruus on oman skeeman nimiavaruus):

1<xs:complexType name="EsimerkkiTyyppi">
2  <xs:sequence>
3    <xs:element ref="jhs:EtuNimi" minOccurs="0"/>
4    <xs:element ref="jhs:SukuNimi" minOccurs="0"/>
5  </xs:sequence>
6</xs:complexType>


Ja vastaava XML voisi olla:

1<Esimerkki>
2  <jhs:EtuNimi>Erkki</jhs:EtuNimi>
3  <jhs:SukuNimi>Esimerkki</jhs:SukuNimi>
4</Esimerkki>


Jos kuitenkin havaitaan, että etunimen pituutta tulisi rajata skeeman julkaisun jälkeen se tehtäisiin seuraavasti:

1<xs:simpleType name="EtuNimiTyyppi">
2  <xs:restriction base="jhs:EtuNimiTyyppi">
3    <xs:maxLength value="50"/>
4  </xs:restriction >
5</xs:simpleType>


Jonka jälkeen validi XML olisi:

1<Esimerkki>
2  <EtuNimi>Erkki</EtuNimi>
3  <jhs:SukuNimi>Esimerkki</jhs:SukuNimi>
4</Esimerkki>


Tämä siirtää automaattisesti EtuNimi-elementin ydintä käyttävän skeeman nimiavaruuteen ja seurauksena rikkoo kaikki dokumentit, jotka ennen olivat skeeman mukaisia. XML-dokumenteissa viitataan elementin kohdalla "vanhaan" JHS-nimiavaruuteen ja elementit ovat näin epäkelpoja uudessa skeemassa. Tämä luo siis rikkovan muutoksen. Uskoisin, että rikkova muutos olisi myös ytimen skeeman uudelleenjärjestely nimiavaruuksien suhteen.

Itse olen varautunut tilanteeseen viittamaalla ainoastaan tyyppeihin ja uudelleen esittelen omassa skeemassa ytimen vastaavat atomaariset elementit, jotka omina versioina eivät luo ytimen viittausvaatimuksia käyttävään XML:ään.

Tässä siis on hyvä huomata suosituksen lause "Tämän vuoksi organisaatio SAA omissa skeemoissaan viitata tyyppimääritykseen." joka mielestäni voi olla jopa suositus näissä tilanteissa, joissa skeemaa hyödyntyvä käyttäjäkunta on laaja sekä ei täysin "oman talon sisällä".

--
Marko Lahma
Digia Oyj
www.digia.com
Flag Flag
RE: Atomaaristen elementti- ja tyyppimääritysten esittely
1.7.2009 4:21 vastauksena Anonyymi:aan.
Hei

Kommentti osuu suosituksen ytimeen. Työryhmässä käytiin runsaasti keskustelua aiheesta.

Lauseen ”Pääsääntöisesti organisaation omissa skeemoissa PITÄISI viitata atomaariseen elementtimääritykseen” takana on pyrkimys tilanteeseen, jossa pystyttäisiin määrittelemään julkishallinnossa yhdessä sovittuja elementtejä, joiden tietotyyppikin olisi yhteisesti sovittu ja hyväksytty. Työryhmässä tuli esille, että tavoite saattaa olla (yli)optimistinen, vaikkakin periaatteessa hyödyllinen ja tavoiteltava. Takana on ollut lisäksi tavoite yksinkertaisesta mallista, jossa yhtä sanaston käsitettä vastaisi yksi XML-skeeman elementti. Koska sanastotyön linjaaminen on vasta alussa JHS-järjestelmän puitteissa, tämän tavoitteen realistisuutta ei ole vielä käytännössä päästy testaamaan.

Käytännössä on huomattu, että organisaatioilla on usein tarve muuttaa ydinskeeman tyyppimäärittelyä omista lähtökohdistaan. Siksi päädyttiin kompromissiin, jossa ytimessä on sekä elementti- että tyyppimäärityksiä. Työryhmässä käytiin keskustelua siitäkin, pitäisikö ytimessä olla VAIN tyyppimäärittelyjä sillä perusteella, että yhteisten elementtimäärittelyjen käyttäminen ei ole realistista tai niiden erikoistaminen organisaation tarpeisiin ei ole suoraviivaista. Kommentteja ja kokemuksia saadaksemme suositukseen jätettiin kuitenkin myös ydinelementtien määrittelyt. Jatkossa on hyvä edelleen käydä keskustelua siitä, onko julkishallinnon yhteisten elementtimäärittelyjen hyödyntäminen realistista, vai pitäisikö ydinskeemassa olla vain tyyppimäärittelyjä, joita on suoraviivaista erikoistaa omiin tarpeisiin.

Jos skeemaa muutetaan sen julkaisun jälkeen, niin tällöin skeemasta tulisi luoda uusi versio. Eli tässä tapauksessa skeemasta olisi kaksi versiota. Ensimmäisessä versiossa EtuNimi kuuluu jhs-nimiavaruuteen ja toisessa versiossa organisaation omaan nimiavaruuteen. Jotta mitään ei rikkoutuisi, vain muutoksen jälkeen tuotettujen XML-dokumenttien tulisi viitata uuteen skeemaversioon. Tämä versiointiratkaisu nähdäkseni ratkaisisi nimiavaruusongelman. Sen sijaan se ei ratkaise sitä, jos muutosta ennen tuotettujen XML-dokumenttien EtuNimi-elementtien pituus pitäisi myös rajata 50 merkkiin, mikä saattaa olla muutoksen luonteen mukaan vaatimuksena.

Periaatteellista keskustelua on käyty työryhmässä ja muissakin yhteyksissä siitä, miten tarkasti tietotyyppejä kannattaa XML-skeemoissa määritellä, jos vastaavat tietotyyppitarkastukset tehdään joka tapauksessa uudestaan sovellustasolla. Yleensä on tultu sellaiseen johtopäätökseen, että tietyn organisaation sisällä XML:n perustyyppien käyttö voisi olla riittävää, koska tietosisältötarkistukset tehdään sovellustasolla. Näin vältetään kaksinkertainen tarkistaminen ja sääntöjen ylläpito. Sen sijaan organisaatioiden välisessä tiedonvaihdossa XML-skeema toimii tavallisesti tietosisällön osalta teknisenä rajapintakuvauksena, jolloin täsmällinen tietotyyppien kuvaaminen on perusteltua.

Lisää kommentteja toivotaan aiheeseen liittyen. Tämän kommentin perusteella näyttää aiempaa vahvemmin siltä, että suorasta viittaamisesta ydinelementteihin saattaa seurata potentiaalisia skeemojen ylläpito-ongelmia.

Lasse Akselin
JHS 170 -suosituksen editori
Tieto Oy
Flag Flag