• Home
• Artikelen
• Boeken
• Downloads
• Contact

Electronic Commerce Modeling Language (ECML)

Wie zich wil storten op het bouwen van een webwinkel, een bestelsysteem of een andere vorm van e-commerce, hoeft daarvoor dankzij PHP en MySQL niet opnieuw het wiel uit te vinden. Je kunt bijvoorbeeld kant-en-klare oplossingen gebruiken zoals Magento (www.magentocommerce.com) en osCommerce (www.oscommerce.com). Minder bekend onder gebruikers van PHP en MySQL is dat er voor e-commerce al bijna tien jaar een aparte internetstandaard bestaat: Electronic Commerce Modeling Language of afgekort ECML.

Voor vooral het dataverkeer bij e-commerce bestaat sinds oktober 1999 een internetstandaard die nog nauwelijks bekend is: Electronic Commerce Modeling Language (ECML). Deze speciale internetstandaard voor e-commerce is vooral belangrijk omdat erin is bepaald welke naam u moet gebruiken voor variabelen. Als samenwerkende webapplicaties allemaal dezelfde variabelennamen accepteren, maakt dat online verkooptransacties veel gemakkelijker. Daarnaast is in ECML vastgelegd welke vorm bepaalde data moeten hebben en kent ECML een apart XML-structuur voor alle data.

Electronic Data Interchange (EDI) via HTML of XHTML

Als internettaal kan ECML worden gebruikt voor het uitwisselen van onder meer klantgegevens, adresgegevens en creditcardgegevens voor transacties met bijvoorbeeld vervoersbedrijven, banken, creditcardmaatschappijen en payment service providers (PSP’s). De gegevens die je vastlegt met PHP-applicaties of opslaat in MySQL-databases, worden dankzij ECML compatibel met systemen van andere bedrijven in het verkoopproces. Tenminste, dat is de bedoeling, want ECML wordt nog weinig gebruikt.

Meer praktisch is ECML vooral belangrijk voor het ontwerpen van formulieren in HTML en Extensible HTML (XHTML). In ECML is namelijk ook vastgelegd welke veldnamen je moet gebruiken in het HTML-element <input name="..." />. Voor de gebruikersverificatie kent ECML bijvoorbeeld de twee veldnamen Ecom_User_ID voor de gebruikersnaam en Ecom_User_Password voor het bijbehorende wachtwoord. In een formulier voor het aanmaken van een gebruikersaccount en later in een formulier voor het inloggen kun je dan de volgende XHTML-code gebruiken:

<form action="..." method="post">
    ...
    <input type="text" name="Ecom_User_ID" />
    ...
    <input type="password" name="Ecom_User_Password" />
    ...
    <input type="hidden" name="Ecom_SchemaVersion" value="urn:ietf:params:ecml:v2.0" />
    ...
</form>

Deze ECML-oplossing zorgt ervoor dat de gebruikersnaam wordt verzonden met de variabelennaam Ecom_User_ID en het gebruikerswachtwoord met de variabelennaam Ecom_User_Password. Het verborgen formulierveld met de naam Ecom_SchemaVersion meldt daarnaast welke datastructuur wordt gebruikt voor deze ECML-gegevens; met de standaardwaarde urn:ietf:params:ecml:v2.0 geef je hier aan webapplicaties door dat er een uniform resource name (URN) wordt gebruikt van de Internet Engineering Task Force (IETF) voor ECML versie 2.0. Dit veld is vereist, vooral om webbrowsers te melden welke versie van ECML ze moeten gebruiken. Browsers kunnen deze melding vervolgens gebruiken om velden alvast te vullen met bijvoorbeeld AutoComplete ofwel AutoAanvullen.

Velden in ECMLv2

De tweede versie ECMLv2 uit juni 2005 (RFC 4112) kent de velden in de tabel aan het einde van dit artikel. De kolom ‘Min.’ noemt de aanbevolen minimumlengte voor elk veld. Alle velden worden uitgebreid toegelicht met noten in RFC 4112 op bijvoorbeeld http://tools.ietf.org/html/rfc4112, http://www.faqs.org/rfcs/rfc4112.html of http://www.rfc-editor.org/rfc/rfc4112.txt.

Merk op dat ECML drie soorten adressen kent: een bezorgadres met het prefix Ecom_ShipTo, een factuuradres met het prefix Ecom_BillTo en een derde adres met het prefix Ecom_ReceiptTo voor bijvoorbeeld een orderbevestiging of kopie van een factuur.

De velden met het prefix Ecom_Payment_Card zijn vooral bedoeld voor creditcards, de velden met Ecom_Loyalty_Card voor klantenkaarten of spaarkaarten en de velden met Ecom_User en Ecom_UserData voor gebruikersaccounts.

Beperkingen van ECML

Houd rekening met de volgende drie beperkingen van ECML. Als je deze internetstandaard wilt gebruiken, zul je enkele velden moeten verwijderen of aanpassen. Daarnaast kan het toevoegen van velden voor bepaalde applicaties zeker geen kwaad.

Verenigde Staten en Amerikaans Engels

Als taal leunt ECML erg op de situatie in de Verenigde Staten en het Amerikaanse Engels. Daardoor is ECML soms minder geschikt voor Europese of Nederlandstalige applicaties.

Een voorbeeld zijn de velden Ecom_ShipTo_Postal_StateProv en Ecom_BillTo_Postal_StateProv. Deze velden zijn bedoeld voor de afkorting van twee letters van een Amerikaanse staat in het bezorgadres (alle velden met het prefix Ecom_ShipTo) en het factuuradres (alles met Ecom_BillTo). In Nederland en België hebben die velden geen betekenis, omdat wij voldoende hebben aan de postcode in Ecom_ShipTo_Postal_PostalCode of Ecom_BillTo_Postal_PostalCode en de plaatsnaam in Ecom_ShipTo_Postal_City of Ecom_BillTo_Postal_City. Je kunt Ecom_ShipTo_Postal_StateProv gebruiken voor een provincie, maar dan wordt het dubbel redundant (overbodig): voor adressen is geen provincie nodig en de provincie is direct af te leiden uit de postcode.

Velden voor een staat of provincie kun je nog weglaten, maar dat geldt helaas niet voor de naam van een klant. Daarvoor gebruikt ECML een oplossing die vaak tot lokalisatieproblemen leidt — en tot usabilityfouten die je vaak aantreft in Nederlandstalige software van Microsoft. Voor namen wordt de typisch Amerikaanse vorm met drie velden gebruikt, bijvoorbeeld Ecom_ShipTo_Postal_Name_First, Ecom_ShipTo_Postal_Name_Middle plus Ecom_ShipTo_Postal_Name_Last. Deze typisch Amerikaanse opzet leidt vaak tot vergelijkbare complicaties, niet alleen in e-commerce maar ook in customer relationship management (CRM).

Wij kennen bijvoorbeeld een duidelijk verschil tussen voornamen en roepnamen. Johannes en Petrus worden Jan of Johan en Piet of Peter. ECML kent dat onderscheid niet, waardoor het veld Ecom_ShipTo_Postal_Name_First slecht bruikbaar wordt. Dat leidt tot dataverlies. Sla je bijvoorbeeld de roepnaam Jan op, dan is niet duidelijk wat de voornaam van de klant is: het kan kortweg Jan zijn, maar ook Johannes. Sla je echter de officiële voornaam Johannes op, dan is niet duidelijk hoe de klant moet worden aangesproken: het kan Jan, Johan of misschien John zijn.

Gebrekkige standaardisatie

De internetstandaard ECML verwijst wel naar bestaande normen van bijvoorbeeld de International Organization for Standardization (ISO), maar past die vaak erg slecht toe. Voor landen in de velden in de velden Ecom_ShipTo_Postal_CountryCode, Ecom_BillTo_Postal_CountryCode en Ecom_ReceiptTo_Postal_CountryCode worden keurig de gestandaardiseerde ISO-landcodes gebruikt, zoals NL voor Nederland en BE voor België. De bedenkers van ECML zijn echter vergeten dat er vergelijkbare ISO-codes bestaan voor talen, zoals nl voor Nederlands, en voor Engels en fr voor Frans. Voor de taal van de gebruikersgegevens gebruikt ECML nu nog het veld Ecom_UserData_Language met een vereiste minimumlengte van dertig karakters. Dat is niet alleen zonde van de opslagruimte. Het leidt ook veel eerder tot fouten, zoals de vervuilde data Nederlands, Dutch, nl-NL en nl voor één taal.

Het opslaan van een taal in een lang tekstveld van minimaal dertig karakters is onhandig, maar dat kunnen we nog vergeven door het een ‘keuze’ te noemen. Andere oplossingen in ECML zijn echt fout. Voor het geslacht verwijst ECML bijvoorbeeld naar de norm ISO/IEC 5218, Information technology -- Codes for the representation of human sexes. Daarvan wordt de sterk verouderde versie gebruikt met de drie letters M van male (mannelijk), F van female (vrouwelijk) en U van unknown (onbekend). Deze actuele versie van ISO-norm 5218 gebruikt echter niet meer drie letters, maar vier integers.

De vernieuwde ISO-norm is om zeker drie redenen beter:

• Een kleine integer kost minder opslagruimte dan een karakter. In MySQL kun je hiervoor het datatype TINYINT(1) UNSIGNED gebruiken in plaats van CHAR(1) of VARCHAR(1).
• Getallen maken een oplossing onafhankelijk van de gebruikte taal. De verouderde U van unknown heeft alleen een betekenis in het Engels. Het verkleint ook de kans op fouten, want sommige Nederlandse webdevelopers zullen geneigd zijn een V in te vullen waar het een F moest zijn.
• Nog belangrijker voor e-commerce is de toevoeging van de vierde toestand 9 voor Niet van toepassing. Als de klant namelijk geen man of vrouw is maar een bedrijf of andere organisatie, is een aparte code geen overbodige luxe.

Praktische implementatie

Sommige oplossingen in ECML zijn niet effectief of werken praktisch gewoon onhandig. In Nederland kan een bestelling worden bezorgd met slechts drie gegevens: de postcode, het huisnummer en een eventuele huisnummertoevoeging (bijvoorbeeld de letter A in huisnummer 123-A). Pakketdiensten die in Nederland opereren. zoals TNT Post (www.tntpost.nl) en DHL van Deutsche Post (www.dhl.nl), gebruiken meestal deze drie velden voor het invoeren van adressen in hun systemen. In ECML worden echter velden gebruikt zoals Ecom_ShipTo_Postal_Street_Line1 en Ecom_ShipTo_Postal_PostalCode. Er is wel een apart veld voor de postcode, maar het huisnummer en de huisnummertoevoeging staan samen met de straatnaam in één veld voor één adresregel. En drie verschillende gegevens opslaan in één veld werkt natuurlijk niet goed als je de bezorging fatsoenlijk wilt automatiseren.

Velden en veldnamen in ECMLv2