Zwykłym sposobem przesyłania danych internetowych między hostami online jest obecnie HTML. Problem z HTML polega na tym, że chodzi głównie o wygląd informacji, a nie o to, co one „oznaczają”. Możemy używać terminów „tytuł”, „autor”, „data publikacji”, „kod ISNB” itp., ale nie mają one specjalnego znaczenia w HTML. Dlatego nie można ich łatwo wybrać automatycznie w większym tekście; nie można też sprawdzić poprawności ciągu, który one reprezentują. Nie możemy na przykład łatwo sprawdzić, czy podana wartość ISBN (np. 0-471-98794-8) składa się z zestawu pól zawierających tylko liczby, oddzielonych myślnikami. Ten brak HTML został w dużej mierze naprawiony w rozwoju Extensible Mark-up Language (XML). XML nadal zapewnia mechanizm układu i wyglądu tekstu, podobnie jak HTML, ale jest znacznie silniejszy w swojej zdolności do nadawania jakiejś formy „znaczenia” wybranym terminom w tekście, a wybór ten jest w dużej mierze w gestii autora . Weźmy przykład z naszej dyskusji o tym, jak opisać konkretną książkę (Networked Futures): chcemy określić, że ma tytuł, autora, wydawcę, identyfikator ISBN, datę i opis. Następnie uproszczony opis XML jest pokazany poniżej
<items> w nawiasach to są tagi. W przedstawionych przykładach każdy z nich reprezentuje typ danych. Informacje istotne dla konkretnego typu tagu to te zawarte między parą <items> i </items> (Użytkownicy HTML będą dobrze zaznajomieni z tą notacją.) W przykładzie widzimy, że istnieje globalny element o nazwie <book> w którym zagnieżdżonych jest wiele innych tagów: <title>, <author>, itd. Pokazaliśmy tylko jedną warstwę zagnieżdżania, ale XML pozwala nam to rozszerzyć w dowolnym stopniu. Na przykład możemy sobie wyobrazić, że tytuł. składał się z dwóch części:
i tak dalej. Korzyść z automatycznego przetwarzania powinna być jasna: ponieważ znaczniki są zdefiniowane i zawierają ciągi danych, programowi znacznie łatwiej jest „zrozumieć”, że „Networked Futures” jest tytułem, a nie autorem lub fragmentem wolnego -opis tekstowy, oczywiście pod warunkiem, że jest świadomy sposobu, w jaki definiujemy książkę i terminów związanych z tą definicją. Jak osiąga się ten ostatni warunek? Musimy upublicznić naszą definicję „książki”. Możemy to zrobić w XML na wiele sposobów, z których jednym jest nagłówek naszego przykładu powyżej z odniesieniem do definicji typu dokumentu (DTD). To kolejny dokument, który zawiera ogólny szablon „książki” i opcjonalnie dodatkowe zasady ułatwiające sprawdzenie poprawności danych. DTD można zlokalizować poprzez jego adres URL. Zakłada się, że strony handlowe, a nawet organizacje międzynarodowe, takie jak organizacje handlowe, mogłyby umieścić swoje DTD i inne dokumenty XML w Internecie, aby handel mógł odbywać się bez dwuznaczności i błędów. W rzeczywistości XML to znacznie więcej, niż przed chwilą omówiliśmy. W szczególności wiele działań dotyczy definiowania, w jaki sposób XML powinien reprezentować prezentację danych w dokumentach elektronicznych, co oczywiście jest przedmiotem zainteresowania projektantów stron internetowych w eCommerce. Jednak to, co omówiliśmy, jest prawdopodobnie najbardziej znaczącym wpływem, jaki XML wywrze na rozwój elektronicznego biznesu: jego potencjał umożliwiający tworzenie standardowych modeli biznesowych dla transakcji automatycznych. Jak dotąd jest to tylko potencjał; siła napędowa musi pochodzić od modelu do technologii, a modele muszą być tworzone w drodze porozumienia. Jak to się stanie, nie jest jeszcze jasne: czy będzie pochodzić od stowarzyszeń branżowych, współpracy opartej na technologii, takiej jak World Wide Web Consortium, czy od dominujących dostawców oprogramowania? Czy zostanie to osiągnięte w sektorach wertykalnych (np. EPICS i ONIX współpracują nad mapowaniem między ich modelem a XML), czy za pomocą międzysektorowych ogólnych definicji handlowych („faktura”, „odwołanie” itp.)? Rzeczywiście, może się zdarzyć, że niektóre wiodące na rynku przedsiębiorstwa podążą za wczesnym modelem EDI i opracują własne modele handlowe. Chociaż w pewnym sensie może to być szkoda, nie będzie to miało tak wyniszczającego efektu, jak to samo podejście dwadzieścia lat temu. Zastrzeżony EDI tworzył blokadę we wszystkich warstwach procesu, od poziomu bajtów w górę. Tworzenie strategii migracji z własnych definicji XML do wspólnego standardu powinno być łatwiejsze. Ale to nie będzie trywialne. Jeszcze przez jakiś czas przedsiębiorstwa będą musiały ostrożnie stąpać po tym obszarze.