Regler kring tecken i XML-meddelanden

Nedan följer olika kategorier av krav på tecken i XML-meddelanden.

Krav på teckentabell (encoding)

Varje tecken (bokstav, siffra eller specialtecken) i en textfil representeras i datorn av ett tal, och kopplingen mellan tal och tecken definieras av en teckentabell. Problemet är att många olika teckentabeller kan användas. Därför går det att i XML-meddelandets början ange en så kallad processorinstruktion med encoding som talar om för mottagaren vilken teckentabell som gäller för det aktuella meddelandet.

UBL ställer krav på att varje XML-meddelande inleds med en processorinstruktion som anger encoding, mer konkret förordas att teckentabellen UTF-8 används hellre än andra alternativ.

Ur Universal Business Language Version 2.1, 04 November 2013:

• [IND2] All UBL instance documents MUST identify their character encoding within the XML declaration.
• [IND3] In conformance with ISO IEC ITU UN/CEFACT eBusiness Memorandum of Understanding Management Group (MOUMG) Resolution 01/08 (MOU/MG01n83) as agreed to by OASIS, all UBL XML SHOULD be expressed using UTF-8.
  

Exempel på processorinstruktion enligt UBL:
<?xml version="1.0" encoding="UTF-8"?>

Vid vissa val av teckentabeller placerar programvaror inledande Byte order mark, BOM, i XML-filerna. Detta kan underlätta igenkänning av använd tabell när sådan inte är explicit angiven, men samtidigt kan det ofta störa programverktyg som inte förberetts för BOM. I och med att UBL begränsats till UTF-8 saknas motiv för att ange BOM i meddelanden med UBL-syntax. Notera också anvisningen av The Unicode Consortium i The Unicode standard, version 12.0, avsnitt 2.6:
”Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature.”

Nationella tecken

Processorinstruktionen är en upplysning för mottagaren om vilken teckentabell som ska användas. Men det räcker inte att den som genererar ett XML-meddelande skriver in en viss encoding i processorinformationen; den som skapar meddelandet måste också se till att det är just denna teckentabell som faktiskt använts när meddelandet skapades. Om en fil som skapats enligt en teckentabell X men tolkas enligt en annan tabell Y blir det problem med de tecken där teckentabellerna skiljer sig åt. Ofta är det de nationella tecknen – som t.ex. ÅåÄäÖö – som visas fel. Lösningen är då att begära att den som skapat XML-meddelandet gör om med rätt teckentabell.

Reserverade tecken i XML

I XML har några tecken har reserverats och tilldelats speciell betydelse. Om dessa reserverade tecken behöver användas för data i XML-meddelanden måste de ersättas med andra tecken enligt de regler som definierats i XML. Berörda tecken framgår av följande tabell:

Reserverat tecken Ersätts med
< (less than) &lt;
> (greater than) &gt;
& (ampersand) &amp;
' (apostrophe) &apos;
" (quotation mark) &quot;

Programvaror som skapar XML-dokument ska sköta växling mellan reserverade tecken och ersättningstecknen med automatik, d.v.s. de reserverade tecken är något som användare normalt inte skall behöva bekymra sig om. Däremot kan reserverade tecken skapa problem vid manuella moment som vid utveckling och test.

Tomma element tillåts inte

De element som inkluderas i ett XML-meddelande i UBL-syntax ska alltid innehålla data. Om utställaren saknar data för ett element, eller klass av element, ska det eller den utelämnas i sin helhet.

I Universal Business Language Version 2.1, 04 November 2013, finns följande regel avseende tomma element:

[IND5] UBL conformant instance documents MUST NOT contain an element devoid of content or containing null values, except in the case of extension, where the UBL ExtensionContent element is used.

Notera att Peppol BIS har fatal-regel för tomma element. Det är den som skapar och skickar affärsdokument som ska se till att regeln om tomma element beaktas.

I enstaka fall kan UBL-syntaxen ställa krav på närvaro av dataelement trots att datamodellen för meddelandet saknar affärsterm. Det framgår i så fall av BIS-dokumentationen hur avsaknaden av affärsterm ska hanteras.

Whitespace och andra utfyllnadstecken

I tillägg till anvisningen om tomma element menar SFTI att uppenbart irrelevanta utfyllnadstecken inte ska användas för att kringgå kravet på innehåll i affärstermer när meddelanden skickas, till exempel genom att infoga datavärden som ”.”, ”-” eller ”N/a”. Detsamma gäller användning av ”whitespace”, dvs tecken som används för att styra horisontal och vertikal förflyttning vid visualisering (t.ex. blanksteg, tabulering, radbrytning), och som ensamma inte kan förmedla meningsfull information om affärstermer.

Peppol:s valideringsregel fångar numera även upp whitespace. Tänk dock på att felsignalen ibland kan vara svårtolkad eftersom whitespace ofta inte genererar ett tydligt visuellt tecken.

Radbrytningstecken ska hanteras i viss text

Dokumentutställare har i princip ingen möjlighet att påverka hur elektroniska affärsdokument ska visas eller skrivas ut. För affärstermer som definierats som text finnas dock en regel om att radbrytning ska hanteras: ”Line breaks in the text may be present, and any line breaks should be preserved and respected by the receiver’s system”, se beskrivningen av datatyp Text i respektive BIS.

Tänk på att radbrytningstecken räknas till kategorin whitespace vilket innebär att XML-programvaror kan vara inställda så att flera radbrytningstecken i följd reduceras till en förekomst. Dessutom brukar inledande och avslutande radbrytningar ignoreras. För SFTI:s referensstilmall har vi begränsat regeln om att beakta radbrytning till Note-elementen.

SFTI:s referensstilmall kan laddas ned från SFTI:s GitHub