The Web Hypertext Application Technology Working Group

Dokument ten jest tłumaczeniem, którego angielska wersja znajduje się na stronie http://www.whatwg.org/charter.
Tłumaczenie zostało wykonane przez zespół T4TW i ELTT

Statut Grupy Roboczej Web Hypertext Application Technology

Wstęp

Deweloperzy oprogramowania w coraz większym stopniu wykorzystują Internet do zamieszczania swoich aplikacji. Aplikacje użytkowników są stosowane do pobierania danych od użytkownika z aplikacji serwerowych, zaś technologie opracowane przez W3C - jak na przykład HTML, CSS i DOM - często są wykorzystywane przy tworzeniu interfejsu użytkownika takich aplikacji. W połączeniu z ECMAScript technologie te stanową fundament aplikacji internetowych.

A jednak wymienione wyżej technologie nie zostały opracowane z myślą o aplikacjach internetowych, a te bardzo często polegają na elementach niezamierzonych przez ich twórców oraz nieopisanych w pełni przez specyfikacje. Następna generacja aplikacji internetowych doda nowych wymagań wobec środowiska programistycznego - będą to wymagania, którym powyższe technologie mogą nie sprostać. Nowe technologie rozwijane przez W3C i IETF mogą wnieść wiele dobrego do rozwoju aplikacji internetowych, jednak technologie te są najczęściej projektowane z myślą o zaspokojeniu innych wymagań i biorą pod uwagę aplikacje internetowe jedynie w stopniu marginalnym.

Dostarczane elementy

Celem Grupy Roboczej Web Hypertext Applications Technology jest zaspokojenie wymagań jednego, spójnego środowiska programistycznego aplikacji internetowych poprzez stworzenie specyfikacji technicznych, które w założeniu mają być w przyszłości zaimplementowane w przeglądarkach internetowych przeznaczonych dla masowego odbiorcy.

Przewidujemy dostarczenie następujących elementów:

Pozostałe elementy, które chcielibyśmy dostarczyć, mogą okazać się potrzebne w uzupełnieniu innych obszarów wymagań aplikacji internetowych. Przykładowo, możemy zająć się specyfikacją nowych elementów semantycznych, które obsługiwałyby typowe zdarzenia, jak choćby te występujące w handlu elektronicznym, na forach, w dziennikach internetowych i grach. Powyższa lista elementów nie jest zamknięta.

Wszystkie specyfikacje opracowane przez grupę roboczą muszą uwzględniać kompatybilność wsteczną i jasno określać rozsądne strategie przejściowe dla twórców. Muszą także przewidywać obsługę błędów, która zapewni współdziałanie nawet, kiedy przyjdzie się zmierzyć z dokumentami, które nie są zgodne z zasadami specyfikacji.

Procedura

Uczestnicy grupy roboczej wnoszą swój wkład w naszą pracę za pomocą archiwizowanej publicznie listy dyskusyjnej, do której każdy może się swobodnie zapisać. Członkowie grupy roboczej powinni także odpowiadać na zapytania innych uczestników listy dyskusyjnej.

Każdemu dokumentowi przypisany jest jego redaktor. Redaktorzy powinni odzwierciedlać w pisanych przez siebie specyfikacjach konsensualną opinię całej grupy roboczej, jednak tylko do redaktora należy przełamywanie impasów, kiedy grupa robocza nie potrafi dojść do porozumienia w jakiejś kwestii.

Specyfikacje rozwijane są publicznie, a najnowsza ich wersja jest zawsze dostępna dla wszystkich. Podczas opracowywania grupa może stwierdzić, że dokument osiągnął stan stabilny i wymaga oceny szerszej grupy ludzi. W takiej sytuacji dokument zostaje zarchiwizowany w swojej aktualnej postaci i ogłoszone zostaje wezwanie do komentowania. Szkice robocze powinny na tym etapie zawierać ostrzeżenie informujące czytelników o tym, że dana specyfikacja nie jest jeszcze gotowa do implementacji w celach innych niż eksperymentalne, oraz że implementacja eksperymentalna wersji roboczej nie powinna być dołączana do produktów przeznaczonych dla zwykłego użytkownika.

Grupa robocza może podjąć decyzję o publikacji stabilnej wersji dokumentu tylko wtedy, gdy zdecydowana większość członków grupy roboczej stwierdzi, że dokument jest już gotowy.

Jeśli wersja robocza, która została udostępniona do komentowania nie otrzyma żadnych użytecznych komentarzy, grupa robocza może stwierdzić, że specyfikacja jest gotowa do implementacji w przeglądarkach internetowych (zarówno w typowych komputerach osobistych jak i w sprzęcie z niższej półki) i do dostarczenia jej zwykłym użytkownikom. Na tym etapie dokument jest archiwizowany i ogłoszone zostaje wezwanie do jego implementacji.

Aby wersja robocza mogła przejść z etapu "wezwania do implementacji" do etapu rekomendacji muszą istnieć przynajmniej dwie współdziałające ze sobą implementacje każdego z elementów. Na potrzeby tego kryterium zdefiniowane zostają następujące terminy:

element
sekcja lub podsekcja specyfikacji.
współdziałające
takie, które zaliczyły poszczególne części pakietu testów.
implementacja
agent użytkownika, który :
  1. implementuje element.
  2. jest dostępny (tzn. można go swobodnie ściągnąć z Internetu lub jest powszechnie dostępny przez inny mechanizm sprzedaży). Spełnienie tego warunku należy udokumentować.
  3. funkcjonuje w spedycji (tzn. wersje programistyczne, prywatne i nieoficjalne nie są wystarczające).
  4. nie jest eksperymentalny (tzn. jest przeznaczony dla szerokiego grona odbiorców i może być powszechnie wykorzystywany).

Jeżeli uzasadnią to opinie na temat implementacji lub, gdy okaże się, że implementacje nie współdziałają w wystarczającym stopniu, specyfikacje na etapie wezwania do implementacji powracają do stanu wersji roboczej by można było zająć się poruszonymi kwestiami i przyczynami różnic między implementacjami.

Członkostwo

Każdy może pomóc poprzez zapisanie się na listę dyskusyjną. Lista osób zapisanych na listę dyskusyjną określana jest terminem uczestnicy.

Członkiem grupy można zostać tylko będąc zaproszonym przez innego członka, który jest reprezentantem producenta przeglądarki internetowej. Grupa ta, określana terminem członkowie zapewnia przewodnictwo i doradztwo, zgodnie z opisem w statucie powyżej. Członkami grupy są w chwili obecnej:

Pytania należy kierować na listę dyskusyjną lub do Iana Hicksona, który reprezentuje naszą grupę.