W ramach W3C powstała także specyfikacja XForms, pozwalająca elegancko i elastycznie opisywać "formatki", które ma pokazywać przeglądarka internetowa. Tymczasem mamy bardzo rozbudowany DOM oraz język JavaScript, mamy technologie, które mogą działać po stronie klienta (Flash, Java, .Net), których możliwości w dziedzinie tworzenia i obsługi formatek są aż nadto wystarczające. Oczywiście, DOM nie ma jednoznacznych interpretacji i każda przeglądarka, a nawet wersja, interpretuje go inaczej (IE, Firefox). Trudno jest stworzyć stronę, która uwzględni wszystkie te subtelności.

Na marginesie warto dodać, że DOM pośrednio pozwolił na znacznie "doskonalsze" metody pishingu (i to zarówno w Internet Explorer, jak i Firefox z obsługą języka XUL). Bez większych problemów można nałożyć na okno potwierdzające "Czy chcesz uruchomić...." własne przyciski i przykryć przycisk "Nie", tak by użytkownik widział słowo "Tak".

Pytanie, czy wprowadzenie XForms coś zmieni? To w końcu tylko kolejny standard, który pozwala zrobić to samo, co inne mechanizmy. Owszem, ma sporo zalet (np. to, że łatwo go generować), ale tak naprawdę są serwery aplikacyjne, które są w stanie generować interfejs do wprowadzania danych do bazy np. w technologii Macromedia Flash. Co więcej, XForm w obecnej formie zostawia trochę pola do samodzielnej interpretacji, jest więc pytanie, czy na pewno autorzy IE i Firefox będą go rozumieć podobnie...

Podobna sytuacja jest z językiem BPEL i ostatnio opracowanym w ramach W3C Web Services Choreography Working Group językiem WS-CDL. W obu przypadkach mamy do czynienia z językami, które (w uproszczeniu) są przeznaczone do wyrażania złożonych procesów biznesowych. W pojedynczej operacji biorą udział różne strony, w przypadku BPEL komunikujące się przy użyciu usług Web. WS-CDL jest raczej językiem do opisywania relacji pomiędzy usługami przy współpracy na zasadach peer-to-peer, i nie wymaga formalnej "orkiestracji" - czyli opisu całego procesu.

BPEL i WS-CDL są tak rozbudowane, że do stworzenia dokumentu z nimi zgodnego niezbędne są w praktyce wyspecjalizowane edytory. Przy tym wszystkim nikt jakoś nie stawia pytania, czy opis procesów biznesowych w formie hierarchicznych zbiorów połączonych z sekwencjami i ewentualnymi rozgałęzieniami warunkowymi jest akurat najwłaściwszym sposobem wyrażania skomplikowanych relacji biznesowych. Czy nie byłby wygodniejszy jakikolwiek inny język programowania? Analityk biznesowy zwykle i tak nie jest w stanie zrozumieć pliku BPEL - najczęściej pracuje z jego wizualną reprezentacją. To co jest pod spodem - XML czy cokolwiek innego, jest dla niego mało istotne.

BPEL ma niby tę zaletę, że może być rozumiany przez różne brokery komunikacyjne. Tak naprawdę trudno jednak wskazać, jakie są realne korzyści wynikające z tego, że możemy łatwo synchronizować diagramy biznesowe między różnymi systemami. Oczywiście, dobrze że obie strony mogą odwoływać się do tych samych pojęć - BPEL ma określone możliwości, narzuca pewien sposób wyrażania procesu itp., ale czy na pewno musi to być XML?

Debata nad schematem

Jednym z ważniejszych elementów technologii XML jest tzw. schemat. Jest to specjalny dokument, który określa strukturę pliku XML. Mając schemat i dokument, można sprawdzić, czy przychodzące informacje są w odpowiednim formacie. Obecnie zwyciężył standard W3C Schema (pliki XSD).

Schemat ma wiele zastosowań. Pozwala z jednej strony szybko sprawdzić, czy dokument jest zgodny z założeniami (czy jest prawidłowy). Pierwszym szeroko przyjętym sposobem opisu struktury XML był DTD. Pozwalał określić, które elementy są wymagane, pozwalał dodać proste ograniczenia na wartości. W przypadku wielu systemów jest to wystarczająca metoda sprawdzenia, czy na wejściu nie znajduje się przypadkiem "śmieć".

W odróżnieniu od DTD, schemat może być także użyty do generowania innych struktur, np. hierarchii klas, które pozwalają obsługiwać dokument o danym schemacie (np. narzędzia dodane do VS .Net, XML Spy itp.). Można też dzięki niemu łatwo przejść pomiędzy strukturą relacyjną a hierarchiczną.

O ile dokument DTD "zwykły" programista jest w stanie szybko przeczytać i zrozumieć już na pierwszy rzut oka, to w przypadku W3C Schema już tak nie jest. Co prawda, powstało wiele narzędzi, które upraszczają pracę ze schematami i tak naprawdę trudno sobie wyobrazić osobę, która byłaby w stanie pracować z plikami XSD bez wyspecjalizowanych edytorów. Ale patrząc z boku, trudno oprzeć się wrażeniu, że w wyniku prac standaryzacyjnych nad XSD powstał "potworek". Być może, gdyby wziąć się za to od nowa, dałoby się stworzyć coś znacznie prostszego, a równie funkcjonalnego.

Niestety, kompromisy i styl pracy W3C spowodował, że w XML Schema można znaleźć elementy z relacyjnych baz danych (no bo, jak zakłada W3C, ktoś może chcieć używać XML jako języka do wymiany danych pomiędzy bazami), elementy zgodne z DTD (no bo trzeba móc przekształcić starszy format schematu do W3C Schema) i tak dalej...

Obecnie nie ma już chyba komercyjnej relacyjnej bazy danych, która nie miałaby w dokumentacji informacji o tym, że "obsługuje XML". Producenci nie piszą jednak, w jakim procencie projektów takie możliwości są praktycznie wykorzystywane. Swoją drogą, ciekawe jest co mają na myśli autorzy niektórych CV, w których piszą, że "znają technologię XML".

Podejście W3C kontrastuje z propozycją RELAX NG - jednym z alternatywnych sposobów opisu schematu XML, który jest znacznie od W3C Schema prostszy, a przez to bardziej czytelny. Tak naprawdę u jego podstaw leży praca dwóch inżynierów, którzy chcieli po prostu stworzyć język do opisu struktury XML - i nic więcej. Według autorów RELAX NG, ich celem było "advancing a lightweight, easy-to-use XML schema language". Praca nad tym standardem objęta jest patronatem OASIS (i jest standardem ISO). Wielu analityków żałuje, że ostatecznie rozpowszechnił się W3C Schema. Może nie jest jeszcze za późno...