Formalia
Nichts ist schlimmer für den E-Commerce, als nicht stattzufinden. Um Hindernisse fürs elektronische Geschäft aus dem Weg zu räumen, hat eine Firmengruppe mit der Electronic Commerce Markup Language festgelegt, wie künftig die Felder in HTML-Formularen ausgezeichnet werden sollen, damit sie sich automatisch ‘ausfüllen’ lassen.
- Henning Behme
Im Netz einzukaufen, kann anstrengend sein, vor allem dann, wenn die Online-Hersteller/Verkäufer oft lange Formulare vorgeben, die man ausfüllen soll. Und wehe, man hat ein Pflichtfeld übersehen, schon geht die gesamte Prozedur von vorn los. Das hemmt das Geschäft. Und deswegen haben eine Reihe Firmen (siehe ‘ECML-Mitglieder’) sich zusammengetan, um einen einheitlichen Satz an Formularfeldnamen zusammenzustellen, den alle interessierten Firmen kostenlos verwenden können. Vor allem hoffen die Beteiligten, dass die Existenz eines solchen Namensvorrats dazu führt, das automatische Ausfüllen von Feldern, die für eine Online-Transaktion erforderlich sind, über Software und Karten zu fördern.
| ECML-Mitglieder | |
|
American Express AOL Brodia Compaq CyberCash Discover FSTC IBM |
Mastercard Microsoft Novell SETCo Sun Microsystems Trintech Visa International |
| Karten | |
| AMER | American Express |
| BANK | Bankcard, Australien |
| DC | DC, Japan |
| DINE | Diners Club |
| DISC | Discover |
| JCB | JCB |
| MAST | Mastercard |
| NIKO | Nikos, Japan |
| SAIS | Saison, Japan |
| UC | UC, Japan |
| UCAR | UCard, Taiwan |
| VISA | Visa |
So genannte digitale Geldbörsen (digital wallets) sollen künftig dafür verantwortlich sein, dass die richtigen - und nur die wichtigen und gewollten - Informationen an den Händler übertragen werden. Dazu gehören Daten wie die Adresse und die Zahlungsmodalität. Und dazu gehören standardisierte Feldnamen, auf die auf der Browser-Seite reagiert werden kann. Einen Entwurf dafür, die Electronic Commerce Modeling Language (ECML), haben Donald Eastlake und Ted Goldstein im Oktober 1999 als RFC 2706 vorgelegt (ECML v1.0) und im Dezember aktualisiert (ECML v1.1). Einer der Mitautoren, Joe Coco von Microsoft, hat parallel dazu an einer beim World Wide Web Consortium (W3C) vorliegenden Note für den Gebrauch von P3P (Platform for Privacy Preferences) im E-Commerce-Umfeld mitgearbeitet.
Inhalt von ECML ist die Definition einer Reihe von hierarchisch organisierten Feldnamen, die sich naturgemäß auf den englischen Sprachraum konzentrieren. Sie sind in die folgenden Kategorien eingeteilt:
- Ecom_ShipTo
- Ecom_BillTo
- Ecom_ReceiptTo
- Ecom_Payment
Außerdem existieren ein paar einzelne Benennungen: Ecom_ConsumerOrderID, Ecom_SchemaVersion, Ecom_WalletID und Ecom_TransactionComplete.
Listing Beispielformular
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>ECML-Test</title>
</head>
<body text="#336633">
<p align="center"><img src="images/ecml.jpg" alt="ECML-Test"></p>
<form action="http://my.server.de/bin/sell_form" method="post">
<p align="center">
<strong>Bitte füllen Sie die folgenden Felder aus:</strong>
</p>
<table>
<tr><td>Eigentümer der Karte:</td>
<td><input type="text" name="Ecom_Payment_Card_Name" size="40"></td>
</tr>
<tr><td>Nummer der Karte</td>
<td><input type="text" name="Ecom_Payment_Card_Number" size="19"></td>
</tr>
<tr><td>Art der Karte: </td>
<td><select name="Ecom_Payment_Card_Type">
<option value="AMER">American Express</option>
<option value="DINE">Diners Club</option>
<option value="MAST">Mastercard/Eurocard</option>
<option value="VISA">Visa</option>
</select></td>
</tr>
<tr><td>Ablaufdatum</td>
<td>Monat: <input type="text"
name="Ecom_Payment_Card_ExpDate_Month" size="2">
Jahr: <input type="text"
name="Ecom_Payment_Card_ExpDate_Year" size="4"></td></tr>
<tr><td><input type="hidden" name="Ecom_Payment_Card_Protocol"></td>
<td><input type="hidden" name="Ecom_SchemaVersion"
value="http://www.ecml.org/version/1.1"></td>
</tr>
<tr><td><input type="submit" value="submit"> </td>
<td><input type="reset"></td>
</tr>
</table>
</form>
</body>
</html>
Die oben genannten Kategorien sind bereits Unterkategorien von Ecom (durch den Unterstrich trennt der Entwurf die Hierarchiestufen), aber sie selbst enthalten Detailinformation, die sich noch weiter in Detailnamen auflösen lassen; beispielsweise Ecom_Payment_Card_Type, dessen Feld das Kürzel einer Kreditkartenfirma erhält. Ecom_Payment_Card_ExpDate, ein weiteres Datum, kann durch die Ergänzung _Month und _Year noch genauer spezifiziert werden. Der Entwurf sieht vor, dass auch aggregierte Daten wie hier Monat und Jahr oder gar sämtliche ShipTo-Daten übertragen werden können. Das obenstehende HTML-Formular und Abbildung 1 zeigen ein einfaches Beispiel, wie diese Feldnamen sich einsetzen lassen. Und der Kasten ‘Versanddaten’ enthält stellvertretend solche, wie sie, auch für die anderen Kategorien existieren - jeweils auf den Teilbereich bezogen.
| Versanddaten: Ecom_ShipTo | |
| Datum | Mindestzeichenmenge |
| Ecom_ShipTo_Postal_Name_Prefix | 4 |
| Ecom_ShipTo_Postal_Name_First | 15 |
| Ecom_ShipTo_Postal_Name_Middle | 15 |
| Ecom_ShipTo_Postal_Name_Last | 15 |
| Ecom_ShipTo_Postal_Name_Suffix | 4 |
| Ecom_ShipTo_Postal_Company | 20 |
| Ecom_ShipTo_Postal_Street_Line1 | 20 |
| Ecom_ShipTo_Postal_Street_Line2 | 20 |
| Ecom_ShipTo_Postal_Street_Line3 | 20 |
| Ecom_ShipTo_Postal_City | 22 |
| Ecom_ShipTo_Postal_StateProv | 2 |
| Ecom_ShipTo_Postal_PostalCode | 14 |
| Ecom_ShipTo_Postal_CountryCode | 2 |
| Ecom_ShipTo_Telecom_Phone_Number | 10 |
| Ecom_ShipTo_Online_Email | 40 |
| Natürlich dürfen Anwender den Vor- oder Nachnamen auch mit mehr als 15 Zeichen vorsehen. | |
| Mindestens am StateProv ist die Fokussierung auf Nordamerika zu erkennen, wo alle Bundesstaaten mit zweibuchstabigen Kürzeln zu bezeichnen sind (AZ für Arizona). | |
Nur ein kleines Pflichtprogramm
Welche der Felder, die die ECML-Namen ausmachen, obligatorisch sind, haben nach wie vor die Anwender zu entscheiden. Aber am Schluss einer Webseite, die Ecom-Felder enthält, muss auf jeden Fall ein verstecktes Feld (input="hidden") mit dem Namen Ecom_SchemaVersion vorhanden sein - es soll klar machen, dass die Übertragung von Daten beendet ist. Außerdem empfehlen die Autoren, für diejenigen Programme, die erst auf Benutzeraktion hin Daten übertragen, ein sichtbares Feld vorzusehen, das man anklicken kann. Schließlich soll Ecom_TransactionComplete vor allem bei mehrseitigen Formularen signalisieren, dass (zunächst) Schluss mit der Übertragung ist.
Überlegungen zur Datensicherheit und darüber, wie Anwender kontrollieren können, wer welche Daten speichert und an wen er sie weitergibt, drängen sich auf. Der ECML-Entwurf verweist auf die RFCs zu Verschlüsselung (SSL/TLS und IPSec) und fordert für öffentlich zugängliche Geräte - etwa in Bibliotheken - die Möglichkeit, die eigenen Daten zu schützen.
In dem Beitrag von Joe Coco und Citibank-Mitarbeitern, der als Note beim W3C vorliegt, wird unter anderem ECML in einer Schema-Notation beschrieben. Die Definition für das Ablaufdatum einer Kreditkarte ist dort ein leeres XML-Element:
<DATA:REF name="Card.ExpDate."
type="Date."
short="Card Expiration Date"
VOC:category="financial" />
woran ein kleiner Unterschied zu ECML gleich auffällt: statt der Unterstriche trennt hier der Punkt die Hierarchie. Ansonsten handelt es sich um eine Abbildung in P3P-Syntax.
Auch das P3P-Papier betont den Sicherheitsaspekt. Es empfiehlt, zumindest solche Daten, die category="financial" enthalten (siehe oben), verschlüsselt zu übertragen - wenn schon nicht alle. (hb)
