Navngivning av XML elementer

Navngivning av XML elementer Versjon 1.0 En anbefaling fra Norsk EDIPRO August 2002 Norsk EDIPRO Tel. 22 12 83 90 Postboks 2526 Soll Fax. 22 12 83 97 0202 Oslo Internet: www.edipro.no

Forord Språket XML, så vel som teknologien rundt, får stadig større utbredelse også i norske miljøer. Det etableres så godt som daglig nye XML-spesifikasjoner og løsninger. Det er imidlertid få eller ingen standardiserte løsninger tilgjengelig. Selve språket XML gir i seg selv heller ingen regler for hvordan XML-dokumentene og navnene på elementer og attributter i disse skal utformes. Dette har medført at det over tid har blitt utviklet en rekke ulike alternativer. Noe som igjen gir problemer ved tolkning og forståelse av XML-dokumenter som er utformet i ulike miljøer. Dette dokumentet er en anbefaling utarbeidet av UTSYN Norsk EDIPROs arbeidsutvalg for meldingsutvikling og syntaks. Hensikten med dokumentet er å bidra til en harmonisering og standardisering av XML-løsninger for å sikre felles tolkning og forståelse av de data som overføres ved hjelp av XML-meldinger. Denne versjonen av dokumentet tar bare for seg en liten, men viktig, del av det totale problemkomplekset. UTSYN har som ambisjon å videreføre arbeidet med harmonisering og standardisering av XML-løsninger. I senere versjoner kan det bli aktuelt å ta opp problemstillinger knyttet til for eksempel: prinsipper for bruk av Core Components i XML-dokumenter konvoluttering ved utveksling av XML-meldinger, herunder bruk av SOAP Dokumentet er på ingen måte noen lærebok i XML og det forventes at leserne har en relativt god kunnskap om utforming av XML-dokumenter. Oslo, 14 august 2002 Jostein Frømyr Leder av UTSYN Copyright Norsk EDIPRO, 2002. All Rights Reserved. Dette dokumentet er utarbeidet av Norsk EDIPROs arbeidsutvalg for meldingsutvikling og syntaks. Dette dokumentet, og oversettelser av det, kan fritt kopieres og distribueres. Dokumentet kan fritt brukes som grunnlag for arbeid som forklarer og/eller kommenterer på innholdet i dokumentet eller på annen måte bidrar til at spesifikasjonen blir tatt i bruk. Slikt avledet arbeid kan fritt utarbeides, kopieres, publiseres og distribueres forutsatt at det gis behørig referanse til dette dokumentet og at det ikke legges begrensninger arbeidet utover det som er definert i denne teksten. Dette dokumentet i seg selv kan imidlertid ikke endres på noen måte med unntak av det som måtte være nødvendig i forbindelse med oversettelse. Dette dokumentet reflekterer de synspunkter og konklusjoner som har fremkommet gjennom arbeid i arbeidsutvalget og ikke nødvendigvis synspunktene til de enkelte deltakerne eller deres arbeidsgivere. Norsk EDIPRO er en brukerstyrt, privat samfunnsgagnlig stiftelse med sete i Oslo. Norsk EDIPROs hovedmål er å fremme bruken av elektronisk handel og forretningsdrift, samt forenklede prosedyrer i næringslivet og mellom næringslivet og den offentlige forvaltning. Norsk EDIPRO skal fokusere på anvendelse av teknologien, samtidig som man skal ha et åpent forhold til eventuell ny teknologi som kan lette innføringen av elektronisk handel. Norsk EDIPROs rolle som nasjonal koordinator og samordningsinstans skal bidra til økt samarbeid mellom ulike miljøer med sikte på å få etablert mest mulige åpne, sikre og funksjonelle elektroniske løsninger i næringslivet og mellom næringslivet og offentlig sektor. UTSYN er Norsk EDIPROs fagutvalg for syntaks og meldingsutvikling. Utvalget er et rent teknisk utvalg som arbeider både med EDIFACT, XML-EDI og andre relevante standarder, samt aktiviteter som skal fremme en harmonisert implementering og anvendelse av disse standarder. 1

Innholdsfortegnelse 1 NAVNGIVNING AV ELEMENTER OG ATTRIBUTTER... 3 1.1 ANBEFALT NAVNEKONVENSJON...3 2 BRUK AV ELEMENTER OG ATTRIBUTTER I XML-DOKUMENTER... 4 2.1 INGEN XML-ATTRIBUTTER...4 2.2 UTELUKKENDE XML-ATTRIBUTTER...4 2.3 STRUKTURELT SKILLE MED XML-ATTRIBUTTER...4 2.4 ANBEFALING...5 2.4.1 Presiseringer og eksempler på bruk av anbefalingene... 5 3 BEHANDLING AV XML-DOKUMENTER... 7 3.1 SAX (SIMPLE API FOR XML)...7 3.2 DOM (DOCUMENT OBJECT MODEL)...7 3.3 JDOM...7 3.4 XPATH...7 3.5 ANBEFALING...8 2

1 Navngivning av elementer og attributter De grunnleggende komponentene i et XML-dokument er elementer og attributter, som begge har verdier. XML gir i seg selv ingen regler for hvordan navnene på elementer og attributter skal utformes noe som har medført at det over tid har blitt utviklet en rekke ulike alternativer. Dette gir igjen problemer ved tolkning og forståelse av XML-dokumenter som er utformet i ulike miljøer. Norsk EDIPRO anbefaler en standard navngivning av elementer og attributter i XML -dokumenter som baserer seg på bruk av Camel Case. Camel Case baserer seg på sammentrekking av ord, og nytt ord begynner med stor bokstav. De store bokstavene vil danne pukler i ordet, derav navnet "Camel Case". I Upper Camel Case (UCC), begynner det første ordet med stor bokstav "InvoiceDate" I Lower Camel Case (LCC), begynner det første ordet med liten bokstav. "measureunit" 1.1 Anbefalt navnekonvensjon Norsk EDIPRO anbefaler at: Elementnavn skrives med UCC (Upper Camel Case) Attributtnavn skrives med LCC (Lower Camel Case) <InvoiceDate dateformat="ddmmyycc >07032001</InvoiceDate> Da vi lever i en verden som er preget av internasjonalisering, er det naturlig å utvikle elementnavn i engelsk språkdrakt. Nasjonalt språk kan om ønskelig benyttes ved utvikling av ledetekster i presentasjonsdokumentene. 3

2 Bruk av elementer og attributter i XML-dokumenter En XML-melding skal overføre informasjon. Informasjon består av innholdsdata og definisjonsdata (metadata). Det er klart avvikende holdninger til hvordan en skal bygge opp en XML-melding, og det er tre klart definerte skoler for dette. Disse er behandlet i de påfølgende kapitlene. Dette heftet tar ikke mål av seg til å gi en fullstendig definisjon av hva som er definisjonsdata og hva som er innholdsdata. Av hensyn til ønsket om å oppnå størst mulig grad av harmonisering av oppbygging av XML-dokumenter for bruk innen ehandel, vil det likevel være nyttig å ha noen konkrete retningslinjer for å skille mellom de to typene informasjon. Som hovedregel kan vi si at innholdsdata beskriver egenskaper ved de objektene som er beskrevet i en melding, mens definisjonsdata er data som kan relateres til fastsettelse av verdi av egenskapene. 2.1 Ingen XML-attributter Denne løsningen benytter ikke muligheten for XML-attributter. En begrunnelse er at det gir enkle modeller, og det kan gi enkle løsninger for å konvertere EDIFACT- og X.12- meldinger til XML. All definisjon av innholdsdata vil ligge i elementnavn, og det gir ikke noe strukturelt skille mellom det som betraktes som definisjonsdata og det reelle datainnholdet. <NetWeight> <MeasureUnit>KGM</MeasureUnit> <CodeList>UN</CodeList> <Value>12000</Value> </NetWeight> Dette er et eksempel på en realisering av denne metoden. Det forutsetter en kunnskap om begrepene for å forstå hva som er definisjonsdata og innholdsdata. 2.2 Utelukkende XML-attributter Denne løsningen benytter utelukkende XML-attributter. Begrunnelsen er at det gir enkle modeller, og det kan gi enkle løsninger for å konvertere EDIFACT- og X.12-meldinger til XML. Dette er identisk med begrunnelsene for løsningen med utelukkende bruk av elementer. I tillegg vil dette gi tomme elementer og derved kortere meldinger. All definisjon av data vil ligge i attributter, og vi har heller ikke her noe strukturelt skille mellom det som betraktes som definisjonsdata og det reelle datainnholdet. <NetWeight measureunit="kgm" codelist="un" value= 12000 /> Dette er et eksempel på en realisering av denne metoden. Som over forutsetter det en kunnskap om begrepene for å forstå hva som er definisjonsdata og innholdsdata. 2.3 Strukturelt skille med XML-attributter De to løsningene som er beskrevet over bygger på en identisk filosofi, men med divergerende realisering - de gir ingen struktur for å skille definisjonsdata og innholdsdata. 4

En struktur på en XML-melding som gir et klart skille mellom det som betraktes som definisjonsdata og hva som er innholdsdata, vil etter vår oppfatning klart være å foretrekke. Det vil gjøre enhver melding lettere å tolke uten å måtte ha en inngående forståelse av fagområdet som meldingen omhandler. Det er derfor nødvendig med felles konvensjoner for plassering av innholdsdata og definisjonsdata i en melding. Eksempel på XML-representasjon som følger denne løsningen er: <NetWeight measureunit="kgm" codelist="un">12000</netweight> Her definerer attributtene måleenhet og hvilken type kodeliste måleenheten er hentet fra, det vil si de uttrykker definisjonsdata. 2.4 Anbefaling Norsk EDIPRO anbefaler følgende konvensjon: Innholdsdata legges som elementverdier innkapslet av starttagg og sluttagg. Definisjonsdata legges som attributtverdier Dette vil gi en meget god lesbarhet og gjøre integrasjon ved transformering enklere. 2.4.1 Presiseringer og eksempler på bruk av anbefalingene Objektene som er beskrevet i en XML-melding for ehandel, vil normalt være basert på en underliggende datamodell (UML-modell). Med dette som utgangspunkt vil Norsk EDIPRO anbefale at følgende mer konkrete konvensjoner blir anvendt for å skille innholdsdata fra definisjonsdata og derved elementtekstinnhold fra attributter: Egenskaper: Verdien av et modellattributt som beskriver en egenskap ved den klassen det står i, legges i XML-meldingen som elementtekstinnhold (data innkapslet av tagger). Attributtnavnet i modellen blir taggnavn i XML-meldingen. <InvoiceDate>07032001</InvoiceDate> Måleenheter: Verdien av et modellattributt som representerer en måleenhet for et annet attributt, legges i XML-meldingen som verdien av et attributt knyttet til det elementet måleenheten gjelder for. Attributtnavnet i modellen blir attributtnavn i XML-meldingen. <NetWeight measureunit="kgm" >12000</NetWeight> Kjente kodelister: Verdien av et modellattributt som identifiserer en kodeliste som forutsettes å være kjent for de applikasjoner som skal behandle XML-meldingen, legges i XML-meldingen som verdien av et attributt knyttet til det elementet kodelisten gjelder for. Attributtnavnet i modellen blir attributtnavn i XML-meldingen. 5

<CountryCode codelist= ISO >NO</CountryCode > Primærnøkler: Verdien av et modellattributt som representerer en objektinstans primærnøkkel, legges i XMLmeldingen som verdien av et attributt knyttet til det elementet som representerer det objektet primærnøkkelen identifiserer. < PurchaseOrder orderid= 1 >2370734056746352</ PurchaseOrder> Subklasseidentifikatorer: Dersom vi i modellen har en assosiasjon til en klasse som identifiserer en av flere mulige spesialiseringer av en superklasse (eller alternativt en assosiasjon til en klasse der assosiasjonen selv identifiserer en av flere mulige spesialiseringer), legges i XMLmeldingen navnet på subklassen (alternativt navnet på assosiasjonen) som en attributtverdi i det elementet som beskriver klassen. <Address subclass= PhysicalAddress >Karl Johans Gate</Address> 6

3 Behandling av XML-dokumenter Det er utviklet flere standardiserte metoder (språk, grensesnitt, mm.) for å kunne behandle XMLdokumenter. Dette er standarder som enten kan anvendes direkte i programmer som skal behandle XML-meldinger eller gjennom verktøy der de er implementert. Vi beskriver i det følgende kort de viktigste av disse behandlingsstandardene. 3.1 SAX (Simple API for XML) SAX (Simple API for XML) er et hendelse-drevet programmeringsgrensesnitt som anvendes for å parse XML-dokumenter. SAX er ikke selv en parser, men beskriver et sett av aksjoner ( callbacks ) som trigges under en sekvensiell traversering av et XML-dokument. Typiske hendelser som sparker slike aksjoner i gang, er dokumentstart, elementstart, elementslutt, dokumentslutt, osv. En typisk SAX-parser er et program for traversering av XML-dokumenter som benytter SAX-hendelsene og fyller de triggede aksjonene med innhold. Resultatet fra en SAX-parser er derfor avhengig av det innholdet man har gitt SAX-aksjonene. Spesifikasjonen av SAX 2.0 finnes på www.megginson.com/sax. 3.2 DOM (Document Object Model) DOM (Document Object Model) er et programmeringsgrensesnitt som er standardisert av W3C for å kunne generere og manipulere struktur og innhold i XML- og HTML-dokumenter (se www.w3.org/tr/dom-level-2-core). DOM definerer en struktur av noder, der hver XMLkomponenttype (element, attributt, kommentar, etc.) har sin egen nodetype. Bruk av DOM forutsetter at denne nodestrukturen representeres som en trestruktur i memory. DOM er derfor et viktig verktøy dersom man trenger å ha samtidig tilgang til hele strukturen og innholdet i et XML-dokument ved behandlingen av dokumentet. Det kan nevnes at SAX ofte brukes som inputmetode når man skal lage et DOM-tre basert på et XML-dokument. 3.3 JDOM Mens DOM er en språknøytral standard, er JDOM utviklet spesielt for Java-miljøet. JDOM er et programmeringsgrensesnitt som likner DOM, men naturlige Java-konstruksjoner brukes på en direkte måte ulike XML-komponenter som elementer, attributter, navnerom, etc. representeres f.eks. som egne Java-klasser med passende egenskaper istedenfor som abtrakte noder slik tilfellet er i DOM. JDOM har fått stor utbredelse i miljøer der Java brukes som plattform ved behandling av XML-dokumenter. For ytterligere informasjon se www.jdom.org. 3.4 Xpath W3C har utviklet en spesifikasjon - XML Path Language (XPath) - som også inneholder en nodebasert modell for XML-dokumenter. Denne modellen har mange likheter med, men også visse avvik fra, DOM-modellen. Den definerer et XML-dokument med en trestruktur bestående av forskjellige typer noder som har forskjellige egenskaper. I tilknytning til Xpath-modellen finnes en konkret syntaks et språk - for å kunne identifisere noder i modellen. En beskrivelse av Xpath kan finnes i XML Path Language (XPath) Version 1.0. For ytterligere informasjon se www.w3.org. 7

XPath inngår som en viktig del av XSLT (XML Stylesheet Language Transformations), som er et språk for å spesifisere transformasjoner av et XML-dokument til en annen form (f.eks. til en annen XML-melding). I XSLT skjer enhver identifikasjon av XML-komponenter som skal gjøres til gjenstand for oversettelse/transformasjon, ved hjelp av Xpath-uttrykk. XSLT er et av de mest aktuelle og anvendelige grunnleggende verktøy ved oversettelse/mapping av XMLehandelsmeldinger. 3.5 Anbefaling Norsk EDIPRO anbefaler at XML-dokumenter skal være konstruert slik at samtlige noder kan traverseres som et gyldig Xpath-uttrykk. XML-dokumenter utformet i henhold til denne anbefalingen vil for eksempel kunne transformeres ved bruk av XSLT. Desverre er det fullt mulig, både ved bruk av XML Schema og XML DTD, å definere et dokument som ikke kan transformeres ved bruk av XSLT. 8