natgillin/translations-raw huggingface dataset:
For example if ISRS Location Code (1-2) is BE use ISRS Location Code (6-8) as the ID for linear referencing with the fairway hectometre (ISRS Location Code 16-20).
eivät ole olennaisia, niillä voi olla eri sisältö id-parin sisällä,
Examples for fairway stretches (valid id element pairs within the fairway_section) that include above defined exceptions:
merkit 6–10 (Fairway section code):
The two NL ISRS Location Codes are a valid definition of a waterway stretch (showing NL exception with respect to the kilometre of the fairway): NLSVG00130K000300191 (km 3,0 at Sas van Gent on the Kanaal Gent-Terneuzen) — NLWDP00130K000400200 (km 4,0 at Westdorpe on the Kanaal Gent-Terneuzen),
[poikkeus]: jos käytetään Belgian ISRS-koodeja NtS WS -palvelussa, väyläosion tunnistamiseen olisi käytettävä vain merkkejä 6–8, koska NtS-viestit julkaistaan yhden väylän eri osuuksilla,
The two BE ISRS Location Codes are a valid definition of a waterway stretch (showing BE exception with respect to the fairway section code (‘020’ Albertkanaal)): BEGNK02016L010100414 (lock of Genk located at km 41,4 on the Albert Canal) — BEOSH02033L010500772 (lock of Ham located at km 77,2 on the Albert Canal).
merkit 11–15 (Object Reference Code):
The following figure shows counter-examples of ISRS Location Code usage for each of the general conventions (no exceptions to the general conventions apply to SK waterway stretches):
merkit 16–20 (Fairway Hectometre):
Invalid ISRS Location Code queries
koostuvat viidestä numeromerkistä, joilla määritellään hehtometri, ja niillä on siten yleensä eri sisältö id-parissa.
General remark: A service to query valid ISRS Location Codes is not supported by the NtS Web Service.
Esimerkki: ”00235” väyläkilometristä 23,5; ”00001” väyläkilometristä 0,1,
The ISRS Location Codes are provided within the European Reference Data Management System (ERDMS).
[poikkeus]: Alankomaiden tapauksessa väylähehtometrin ja väylän fyysisen kilometrin välillä ei ole aina suoraa yhteyttä, mikä johtuu väyläosuuden alkupisteen määrittelystä verkostomallissa ja todellisuudessa.
The correct usage of ISRS Location Codes in queries and their interpretation is given in the following five cases.
Tällaisissa tapauksissa ”dismar”-tyyppisten kohteiden Object Reference Code -koodin alussa on Kxxxx (xxxx sisältää fyysisen kilometrin, esim. NLSVG00130K000300191 (3 km)).
Case 1: No ids element in request
Muiden kohdetyyppien osalta ISRS-koodeissa ei kuitenkaan ole suoraa yhteyttä fyysiseen väyläkilometriin, esim. samalla väylällä kohdassa 2,5 km sijaitsevan Sas van Gentin sillan ISRS-koodi on NLSVG001300521600186.
The ids element is an optional part of the request, i.e. a query without any ids elements is allowed:
Kanaal Gent-Terneuzenin fyysinen km 0,0 alkaa Belgian ja Alankomaiden rajalla ja väylähehtometri 0,0 alkaa kanavan alkupisteessä Gentissä.
Valid query without ids parameter
Jos viesti koskee useampaa kuin yhtä vesiväylää tai väyläosiota, kaikki väyläosiot on määriteltävä niiden alkamis- ja päättymiskohdan avulla erillisissä väyläosiota (”fairway_section”) koskevissa XML-elementeissä.
If no ids element is given, all messages shall be returned (depending, of course, on other filter criteria like validity_period or dates_issue).
Joidenkin maiden/alueiden osalta on kehitettävä suodatintoiminto.
Case 2: One id element in request
Esimerkiksi, jos ISRS Location Code -koodi (1–2) on BE, on käytettävä ISRS Location Code -koodia (6–8) ID:nä lineaarisessa viittaamisessa väylähehtometriin (ISRS Location Code -koodi 16–20).
Each ids element can contain one or two id elements.
Esimerkkejä väyläosuuksista (pätevät id-elementtiparit väyläosiolla), joihin sisältyvät edellä määritellyt poikkeukset:
The case of one id element is shown in the following figure:
Vesiväylän osuus voidaan määrittää pätevästi kahden NL ISRS Location Code -koodin avulla (niistä ilmenee väyläkilometrin osalta sovellettava NL-poikkeus): NLSVG00130K000300191 (km 3,0 Sas van Gentissä Kanaal Gent-Terneuzen -kanavassa) – NLWDP00130K000400200 (km 4,0 Westdorpessa Kanaal Gent-Terneuzen -kanavassa).
Valid query with one id parameter
Vesiväylän osuus voidaan määrittää pätevästi kahden BE ISRS Location Code -koodin avulla (niistä ilmenee fairway section code -koodin (”020” Albertkanaal) osalta sovellettava BE-poikkeus): BEGNK02016L010100414 (Genk-sulku, joka sijaitsee km:ssä 41,4 Albert Canal -kanavassa) – BEOSH02033L010500772 (Ham-sulku, joka sijaitsee km:ssä 77,2 Albert Canal -kanavassa).
If such a query is received, the server shall return all matching messages with a start hectometre ≤ the given value (240,7 in the example) and an end hectometre ≥ this value.
Seuraavassa kuviossa esitetään vastaesimerkkejä ISRS Location Code -koodien käytöstä kunkin yleisen käytännön osalta (poikkeuksia yleisistä käytännöistä ei sovelleta SK:n vesiväyläosuuksiin):
The figure below depicts this selection of messages: The position queried lies between the start and end hectometre values of messages 1, 3 and 4, which would be returned.
Virheelliset ISRS Location Code -haut
Messages 2, 5 and 6 do not overlap with the query position, so they would not be returned.
Yleinen huomautus: NtS Web Service ei tue voimassa olevien ISRS Location Code -koodien hakemista.
If the given ISRS Location Code denotes a singular object, e.g. a gauge or a lock, the web service should return the messages involving this object.
ISRS Location Codes -koodit löytyvät Euroopan komission ylläpitämästä sähköisestä asiakirjojen ja tietojen hallintajärjestelmästä (ERDMS).
Matching and not matching messages for one id parameter
ISRS Location Codes -koodien oikeaa käyttöä tehtäessä hakuja ja niiden tulkintaa kuvataan seuraavissa viidessä tapausesimerkissä:
Case 3: Two id elements in request
Tapaus 1: Pyyntöön ei sisälly ids-elementtiä
The case of two id elements is shown in the following figure:
Ids-elementti on pyynnön valinnainen osa, ts. pyyntö voidaan tehdä ilman ids-elementtiä:
Valid query with two id parameters
Hyväksyttävä haku ilman ids-parametriä
All hectometre values queried shall be treated as valid, even if the corresponding fairway section has different start or end points.
Jos ids-elementtiä ei syötetä, kaikki viestit palautetaan (riippuen tietysti muista suodatinperusteista, kuten validity_period tai dates_issue).
For instance, if the fairway section starts at hectometre 100,0 and ends at hectometre 300,0, a request querying hectometres 20,0 up to 400,0 would be valid.
Tapaus 2: Pyyntöön sisältyy yksi id-elementti
Internally, of course, only the ‘real’ extent of the fairway section is searched.
Kukin ids-elementti voi sisältää yhden tai kaksi id-elementtiä.
Doing so also enables the search for all messages on a fairway without knowing its exact hectometre range (one would send its ISRS Location Code with hectometres set to ‘00000’ or ‘99999’ respectively).
Tapaus, jossa pyyntöön sisältyy yksi id-elementti, esitetään seuraavassa kuviossa:
All matching messages intersecting the given hectometre interval shall be returned.
Yhden id-parametrin sisältävä hyväksyttävä haku
The following diagram illustrates this situation:
Jos tällainen haku vastaanotetaan, palvelin palauttaa kaikki sitä sopivat viestit, joissa alkupisteen hehtometri ≤ annettu arvo (esimerkissä 240,7) ja loppupisteen hehtometri ≥ tämä arvo.
Matching and not matching messages for two id parameters
Tämä viestin valinta esitetään seuraavassa kuviossa: Haettu kohta sijaitsee viestien 1, 3 ja 4 alku- ja loppupisteen hehtometriarvojen välillä, joten kyseiset viestit palautettaisiin.
The figure above shows, how ‘intersecting’ is defined.
Viestit 2, 5 ja 6 eivät mene päällekkäin haetun kohdan kanssa, joten niitä ei palautettaisi.
While the extents of the messages 1 to 4 overlap with the extent of the queried hectometre range (partially or completely), the extents of messages 5 and 6 do not, therefore messages 1 to 4 will be returned, 5 and 6 will not be returned.
Jos annettu ISRS Location Code -koodi ilmaisee yhtä yksittäistä kohdetta, esim. vedenkorkeusmittaria tai sulkua, web service -palvelun pitäisi palauttaa tätä kohdetta koskevat viestit.
The technical condition for a message to intersect with an interval [A, B] is: The start hectometre of the message is ≤ B and its end hectometre is ≥ A.
Yhtä id-parametriä vastaavat ja vastaamattomat viestit
Valid query with multiple ids elements
Tapaus, jossa pyyntöön sisältyy kaksi id-elementtiä, esitetään seuraavassa kuviossa:
The combination of several ids elements in the request leads to a union of the corresponding messages.
Kaksi id-parametriä sisältävä hyväksyttävä haku
All the ids elements are treated individually and a message will be returned, if it matches at least one of them.
Kaikkia haettuja hehtometriarvoja pidetään hyväksyttävinä, vaikka vastaavalla väyläosuudella on erilainen alku- tai loppupiste.
Therefore, the following messages would be returned for the given example:
Esimerkiksi, jos väyläosio alkaa hehtometrissä 100,0 ja päättyy hehtometrissä 300,0, hehtometrejä 20,0–400,0 koskeva haku olisi hyväksyttävä.
All messages for the object with the ISRS Location Code SKXXX0000010000***** with start hectometre =0 and end hectometre ≥ 0 (see Case 2)
Sisäisesti haetaan tietysti vain väyläosion ”todellinen” laajuus.
All messages for the object with the ISRS Location Code SKXXX0000500000***** which intersect the hectometre interval [11,0, 15,0] (see Case 3) — All messages for the object with the ISRS Location Code SKXXX0000200000***** with start hectometre ≤ 110,5 and end hectometre ≥ 110,5 (see Case 2)
Näin on myös mahdollista hakea kaikkia väylää koskevia viestejä tietämättä sen tarkkaa hehtometrimäärää (väylän ISRS Location Code -koodissa hehtometreiksi olisi määritetty ”00000” tai ”99999”).
All messages for the object with the ISRS Location Code SKXXX0000500000***** which intersect the hectometre interval [220,0, 300,0] (see Case 3)
Kaikki annetun hehtometrivälin kanssa risteävät sopivat viestit palautetaan.
In this chapter the implementation specification of the NtS message service is given, deduced from the considerations and choices in the preceding chapters.
Tätä tilannetta kuvataan seuraavassa diagrammissa:
The NtS message service provides the four types of messages in the NtS:
Kahta id-parametriä vastaavat ja vastaamattomat viestit
NtS FTM (fairway and traffic related message)
Edellä oleva kuvio osoittaa, miten ”risteäminen” määritellään.
NtS WRM (water related message)
Viestien 1–4 käsittämä alue menee (osittain tai kokonaan) päällekkäin haetun hehtometrivälin kanssa, toisin kuin viestien 5 ja 6 käsittämä alue, joten viestit 1–4 palautetaan ja viestejä 5 ja 6 ei palauteta.
NtS ICEM (ice message)
Tekninen edellytys viestin risteämiselle välin [A, B] kanssa on: viestin alkupisteen hehtometri on ≤ B ja sen loppupisteen hehtometri on ≥ A.
NtS WERM (weather related message)
Yhdistelmä: Pyyntöön sisältyy useita ids-elementtejä
An implementation of the NtS message service can support all message types or just a selection.
Useita ids-elementtejä sisältävä hyväksyttävä haku
It is allowed that a participating Member State provides more than one service for a specific message type, that complement each other.
Useiden ids-elementtien yhdistelmä pyynnössä johtaa vastaavien viestien yhdistämiseen.
In order to achieve a maximum robustness of the service while keeping the complexity on a low level no additional query language is used for the NtS Web Service.
Kaikkia ids-elementtejä käsitellään erikseen, ja viesti palautetaan, jos se vastaa ainakin yhtä niistä.
Instead the constructs provided by WSDL itself are applied.
Annetusta esimerkistä palautettaisiin siten seuraavat viestit:
The specific operations together with their parameters are specified entirely within the WSDL specification.
kaikki kohdetta, jonka ISRS Location Code -koodi on SKXXX0000010000*****, koskevat viestit, joissa alkupisteen hehtometri = 0 ja loppupisteen hehtometri ≥ 0 (ks. Tapaus 2)
In the case of the NtS Message Service a single operation is defined.
kaikki kohdetta, jonka ISRS Location Code -koodi on SKXXX0000500000*****, koskevat viestit, jotka risteävät hehtometrivälin [220,0, 300,0] kanssa (ks. Tapaus 3).
The subject-specific filter criteria are taken from the NtS standard, but extended concerning multiplicity of the parameters:
Tähän lukuun sisältyy NtS-viestipalvelun toteutusta koskeva eritelmä, joka pohjautuu edellisissä luvuissa esitettyihin näkökohtiin ja vaihtoehtoihin.
type of message (compulsory; one of ‘FTM’, ‘WRM’, ‘ICEM’, ‘WERM’),
NtS-viestipalvelu mahdollistaa neljä NtS-järjestelmän viestityyppiä:
specific waterway sections or parts thereof, or specific objects (optional; described by single ISRS Location Codes and/or pairs of ISRS Location Codes),
NtS FTM (väylää tai liikennetiedotusta koskeva viesti)
time of validity (optional; start date and end date),
NtS WRM (vesitilannetta koskeva viesti)
date of publication of the notice (optional; single dates and/or intervals of dates).
NtS ICEM (jäätilannetta koskeva viesti)
Only the messages matching the given criteria are returned by the service.
NtS WERM (säätä koskeva viesti).
Paging mechanism
NtS-viestipalvelun toteutus voi tukea kaikkia viestityyppejä tai vain osaa niistä.
In order to control the amount of data a paging mechanism is supported.
Osallistuva jäsenvaltio voi tarjota tiettyä viestityyppiä varten useampia palveluja, jotka täydentävät toisiaan.
The paging parameter is defined with a complex type containing the following elements:
Jotta taataan palvelun mahdollisimman suuri häiriönsietokyky ja samanaikaisesti sen helppokäyttöisyys, NtS Web Service -palvelussa ei käytetä lisäksi erillistä hakukieltä.
offset: serial number of the first returned message (integer ≥ 0),
Sen sijaan sovelletaan WSDL-kielen omia rakenteita.
limit: max. number of messages (integer ≥ 0),
Toiminnot ja niitä koskevat parametrit määritetään kokonaisuudessaan WSDL-spesifikaatiossa.
total count: flag, if total number of messages shall be returned (Boolean value).
NtS-viestipalvelun tapauksessa määritellään yksittäinen toiminto.
The complex paging parameter is optional, but if it is present, all elements within have to be given.
Aihekohtaiset suodatusperusteet otetaan NtS-standardista, mutta niitä laajennetaan parametrien monilukuisuuden mukaan:
Then, the paging mechanism works in the following way:
viestityyppi (pakollinen; ”FTM”, ”WRM”, ”ICEM”, ”WERM”)
The total number of messages will not exceed the value of the parameter limit, with the exception that a value of 0 means ‘no limit’.
vesiväyläosiot tai niiden osat tai kohteet (valinnainen; niitä kuvataan yhdellä ISRS Location Code -koodilla ja/tai ISRS Location Code -koodiparilla)
The response skips as many messages as defined in the parameter offset.
voimassaoloaika (valinnainen; alkamispäivä ja loppumispäivä)
In order to provide this mechanism, the service has to observe a temporarily stable (but otherwise arbitrary) sequence of the messages, e.g. between two updates of message data on the underlying data set of the web service.
ilmoituksen julkaisupäivä (valinnainen; yksittäinen päivämäärä ja/tai aikaväli)
This means that two consecutive identical calls must return the same messages in the same order.
Palvelu palauttaa vain viestit, jotka vastaavat annettuja kriteerejä.
The parameter total count determines whether the response shall provide the total number of messages matching the subject-specific criteria.
Sivutusmekanismi
Usually it should be sufficient to request this information with the first response, but omit it in all consecutive responses.
Tietomäärän hallitsemiseksi palvelu tukee sivutusmekanismia.
This should result in a better performance of the web service.
Sivutusparametri määritellään kompleksityypillä, joka sisältää seuraavat elementit:
The paging mechanism provides a means to request the messages iteratively in ‘pages’.
offset: ensimmäisen palautetun viestin sarjanumero (integer ≥ 0)
In order for the paging mechanism to work properly, the same subject-specific parameters have to be provided in each call.
limit: viestien enimmäismäärä (integer ≥ 0)
In case of a successful request the NtS Web Service response contains the NtS messages that match the request parameters.
total count: lippu, jos palautetaan viestien kokonaismäärä (Boolean-arvo).
The NtS messages have to comply with the NtS schema and can be validated against that schema.
Sivutusparametrikompleksi on valinnainen, mutta jos sitä käytetään, kaikki siihen sisältyvät elementit on mainittava.
Since the message type is a compulsory request parameter, each response can contain only NtS messages of the same message type, FTM, WRM, ICEM or WERM respectively.
Sivutusmekanismi toimii seuraavalla tavalla:
If the service detects errors while processing the request it can return an arbitrary number of error messages, using the error codes listed in the following subchapter.
Viestien kokonaismäärä ei ylitä limit-parametrin arvoa sillä poikkeuksella, että arvo 0 tarkoittaa ”ei ylärajaa”.
One response of an NtS Web Service can contain NtS messages and error messages at the same time.
Vastauksessa ohitetaan offset-parametrissä määritelty määrä viestejä.
Optional paging information is returned if the request contained paging parameters.
Tämän mekanismin tarjoamiseksi palvelussa on noudatettava tilapäisesti vakaata (mutta muutoin mielivaltaista) viestien järjestystä, esim. kun viestin tietoja on päivitetty kahdesti web service -palvelun perustana olevien tietojen perusteella.
In this case the offset and number of contained messages are mandatory, the total count needs only be present if it has been requested.
Tämä tarkoittaa, että kahden peräkkäisen identtisen pyynnön on palautettava samat viestit samassa järjestyksessä.
Please note: It is assumed that the communication between the web service and the user is technically established, i.e. the service receives the request and the user receives the corresponding response.
Total count -parametri määrittää, sisältääkö vastaus kaikki aihekohtaisia kriteerejä vastaavat viestit.
Technical errors, e.g. breakdown of the internet connection or inaccessibility of the web service due to maintenance or crash, are not considered here.
Yleensä pitäisi riittää, että tätä tietoa pyydetään ensimmäisessä vastauksessa, mutta se jätetään pois kaikista myöhemmistä vastauksista.
Only error situations that happen ‘behind’ the web service layer from the users point of view are considered here.
Tämän on määrä parantaa web service -palvelun suorituskykyä.
Error messages
Sivutusmekanismi mahdollistaa viestien pyytämisen iteroivasti ”sivuina”.
The error codes for the expected error situations are given below, together with an explanation.
Jotta sivutusmekanismi toimii asianmukaisesti, jokaisessa pyynnössä on annettava samat aihekohtaiset parametrit.
Only the error code is contained in the response, which is the usual procedure in the XML schema of the NtS.
Kun NtS Web Service -palvelussa tehtävä haku on onnistunut, vastaus käsittää pyynnön sisältämiä parametrejä vastaavat NtS-viestit.
Error codes for the NtS message service
NtS-viestien on oltava NtS-skeeman mukaisia, ja ne voidaan validoida tätä skeemaa vastaan.
If the contract-first approach is consequently observed, i.e. one or more contracts with complete descriptions of the interfaces are given in the form of WSDL documents, an implementation of the service(s) as well as an implementation of a corresponding client can be automatically generated using appropriate software tools.
Viestityyppi on pakollinen parametri pyynnössä, joten vastaus voi sisältää vain samaa viestityyppiä (FTM, WRM, ICEM tai WERM) edustavia NtS-viestejä.
In an ideal situation no manual changes have to be made in the generated source code.
Jos palvelu havaitsee virheitä käsitellessään pyyntöä, se voi palauttaa satunnaisen määrän virheilmoituksia käyttäen seuraavassa jaksossa lueteltuja virhekoodeja.
However, in most cases several iterations are necessary until the WSDL specification meets the precise requirements of such a tool.
NtS Web Service -palvelun vastaus voi sisältää samanaikaisesti NtS-viestejä ja virheilmoituksia.
Typically the tool makes individual demands on the use of the WSDL standard in order to work smoothly.
Valinnaiset sivutustiedot palautetaan, jos pyyntö sisälsi sivutusparametrejä.
As a consequence changes to the WSDL specification may be necessary, although the WSDL specification was a valid specification according to the WSDL standard in the first place.
Tässä tapauksessa poikkeutus (offset) ja sisältyvien viestien määrä ovat pakollisia, mutta viestien kokonaismäärä on ilmoitettava vain, jos sitä on pyydetty.
If the WSDL specification of the web service is changed after the service or the client have been generated, a new generation process may be necessary, depending on the changes made.
Huom. Web service -palvelun ja käyttäjän välisen viestinnän oletetaan olevan teknisesti vakiintunutta, ts. palvelu vastaanottaa pyynnön, ja käyttäjä vastaanottaa sitä vastaavan vastauksen.
Term
Tässä yhteydessä ei tarkastella teknisiä virheitä, esim. internetyhteyden katkeamista tai sitä, ettei web service -palvelu ole käytettävissä huoltotoimenpiteiden tai palvelun kaatumisen vuoksi.
Explanation
Huomioon otetaan vain virhetilanteet, jotka tapahtuvat käyttäjien näkökulmasta web service -tason ”takana”.
Identification
Virheilmoitukset
Simple Object Access Protocol; network protocol typically used for web services
Odotettavissa olevien virhetilanteiden virhekoodit esitetään alla yhdessä selityksen kanssa.
Universal Description, Discovery and Integration; Standard for registry services in the context of web services
Vastaukseen sisältyy vain virhekoodi, mikä on tavanomainen toimintatapa NtS:n XML-kaaviossa.
United Nations
NtS-viestipalvelua koskevat virheilmoitukset
Uniform Resource Locator; location of a network resource typically used for internet addresses
Jos noudatetaan johdonmukaisesti sopimus ensin -lähestymistapaa (contract-first), ts. yksi tai useita sopimuksia rajapintojen täydellisine kuvauksineen esitetään WSDL-dokumenttien muodossa, palvelu(je)n käyttöönotto ja vastaavan asiakkaan käyttöönotto voidaan luoda automaattisesti käyttämällä asianmukaisia ohjelmistotyökaluja.
World Geodetic System 1984
Ihannetapauksessa luotuun lähdekoodiin ei tarvitse tehdä muutoksia manuaalisesti.
Web Services Description Language; standard for the specification of web services
Työkalu antaa tyypillisesti yksittäisiä käskyjä WSDL-standardin käytöstä, jotta se toimii sujuvasti.
Extensible Markup Language; meta language for the structured and platform independent representation of data
Jos verkkopalvelun WSDL-spesifikaatioa muutetaan palvelun tai asiakkaan luomisen jälkeen, uusi luontiprosessi voi olla tarpeen tehdyistä muutoksista riippuen.
XML Schema Definition; standard to specify the structure of XML documents
Termi
Description cited from the WS-I Website: http://www.ws-i.org
Selitys
In order to ensure that Member States are able to encode Notices to Skippers messages in a consistent and interoperable manner, the Reference tables included in Appendix E should be improved.
Tunniste
For this purpose, new codes should be defined in a new Reference table containing harmonised search interface labels for the graphical user interface.
Simple Object Access Protocol; verkkopalveluissa tyypillisesti käytettävä verkkoprotokolla
a specific waterway section;
Universal Description, Discovery and Integration; rekisteröintipalveluja koskeva standardi verkkopalvelujen yhteydessä
a specific part of a waterway, defined by the river-km of the starting and the end point; (e) time of validity of the notice (start date and end date of validity period);
Yhdistyneet kansakunnat
Yes:
Uniform Resource Locator; internetosoitteissa tyypillisesti käytettävä verkkoresurssin sijaintipaikka
Reason_code
World Geodetic System 1984; maailman geodeettinen koordinaattijärjestelmä vuodelta 1984
Reporting_code
Verkkopalvelu; palvelu, joka tarjoaa liityntöjään internetissä ja jota käytetään internetviestinnän avulla
Communication_code
Web Services Description Language; verkkopalvelujen spesifikaatiota koskeva standardi
Ice_condition_code
Web Services Interoperability Organisation; teollisuuskonsortio, jonka tavoitteena on tukea verkkopalvelujen yhteentoimivuutta
Ice_accessibility_code
Extensible Markup Language; metakieli, jota käytetään datan jäsenneltyyn ja alustasta riippumattomaan esittämiseen