3. Definicja zgodności ze standardem

Ten rozdział ma charakter normatywny.

By upewnić się, że dokumenty rodziny XHTML są w największym stopniu przenośne między programami użytkownika rodziny XHTML, niniejsza specyfikacja sztywno definiuje warunki zgodności ze standardem dla dokumentów, programów użytkownika oraz typów dokumentów rodziny XHTML. Definicje zgodności ze standardem znajdujące się w tym rozdziale z konieczności odwołują się do normatywnego tekstu zawartego w tym dokumencie, w bazowej specyfikacji XHTML [XHTML1] i w innych powiązanych specyfikacjach. Pełne zrozumienie wymagań zgodności ze standardem XHTML jest możliwe jedynie poprzez przeczytanie wszystkich normatywnych odnośników.

Słowa kluczowe „MUSI” (ang. „MUST”), „NIE MOŻE” (ang. „MUST NOT”), „WYMAGANY” (ang. „REQUIRED”), „BĘDZIE / MA” w znaczeniu powinności (ang. „SHALL”), „NIE BĘDZIE / NIE MA” w znaczeniu powinności (ang. „SHALL NOT”), „POWINIEN” (ang. „SHOULD”), „ZALECANY” (ang. „RECOMMENDED”), „MOŻE” (ang. „MAY”) i „OPCJONALNY” (ang. „OPTIONAL”) w tym dokumencie są interpretowane w sposób opisany w [RFC2119].

3.1. Zgodność typów dokumentu ze standardem XHTML Host Language

Jest możliwe modyfikowanie istniejących typów dokumentu oraz definiowania całkowicie nowych typów dokumentu przy użyciu modułów zdefiniowanych w tej specyfikacji, jak i innych modułów. Taki typ dokumentu jest „zgodny ze standardem XHTML Host Language”, gdy spełnia następujące kryteria:

1. Typ dokumentu musi być zdefiniowany przy użyciu jednej z metod implementacji zdefiniowanych przez W3C. Obecnie ogranicza się to do DTD XML, lecz wkrótce będzie dostępne także XML Schema. Pozostała część tego rozdziału odnosi się do „DTD”, choć inne implementacje są także możliwe.
2. DTD, które definiuje typ dokumentu musi posiadać unikatowy identyfikator stosujący się do definicji zawartych w rozdziale Reguły nazewnictwa, który w pierwszym leksemie opisu tekstu publicznego używa łańcucha „XHTML”.
3. DTD, które definiuje typ dokumentu, musi zawierać przynajmniej moduły Structure, Hypertext, Text i List zdefiniowane w tej specyfikacji.
4. Dla każdego ze zdefiniowanych przez W3C modułów, które są załączone, wszystkie elementy, atrybuty, typy atrybutów (łącznie z wszystkimi obowiązkowymi wykazami wyliczonych wartości) i wszystkie wymagane modele minimalnej zawartości muszą być zawarte (i opcjonalnie rozszerzone) w modelu zawartości typu dokumentu. Gdy modele zawartości są rozszerzone, wszystkie elementy i atrybuty (razem z ich typami lub jakimikolwiek obowiązkowymi wykazami wyliczonych wartości) wymagane w oryginalnym modelu zawartości muszą pozostać wymaganymi.
5. DTD, które definiuje typ dokumentu może definiować dodatkowe elementy i atrybuty, jednak muszą one znajdować się we własnej przestrzeni nazw XML [XMLNAMES].

3.2. Zgodność typów dokumentu ze standardem XHTML Integration Set

Jest także możliwe zdefiniowanie typów dokumentu, które bazują na XHTML, ale nie stosują się do jego struktury. Taki typ dokumentu jest „zgodny ze standardem XHTML Integration Set”, gdy spełnia następujące kryteria:

1. Typ dokumentu musi być zdefiniowany przy użyciu jednej z metod implementacji zdefiniowanych przez W3C. Obecnie ogranicza się to do DTD XML, lecz wkrótce będzie dostępne także XML Schema. Pozostała część tego rozdziału odnosi się do „DTD”, choć inne implementacje są także możliwe.
2. DTD, które definiuje typ dokumentu musi posiadać unikatowy identyfikator stosujący się do definicji zawartych w rozdziale Reguły nazewnictwa, który używa łańcucha „XHTML” NIE w pierwszym leksemie opisu tekstu publicznego.
3. DTD, które definiuje typ dokumentu, musi zawierać przynajmniej moduły Hypertext, Text i List zdefiniowane w tej specyfikacji.
4. Dla każdego ze zdefiniowanych przez W3C modułów, które są załączone, wszystkie elementy, atrybuty, typy atrybutów (łącznie z wszystkimi obowiązkowymi wykazami wyliczeniowymi) i wszystkie wymagane modele minimalnej zawartości muszą być zawarte (i opcjonalnie rozszerzone) w modelu zawartości typu dokumentu. Gdy modele zawartości są rozszerzone, wszystkie elementy i atrybuty (razem z ich typami lub jakimikolwiek obowiązkowymi wykazami wyliczonych wartości) wymagane w oryginalnym modelu zawartości muszą pozostać wymaganymi.
5. DTD, które definiuje typ dokumentu może definiować dodatkowe elementy i atrybuty, jednak muszą one znajdować się we własnej przestrzeni nazw XML [XMLNAMES].

3.3. Zgodność ze standardem modułów rodziny XHTML

Ta specyfikacja definiuje metodę definiowania modułów zgodnych z XHTML. Moduł jest zgodny z tą specyfikacją, gdy spełnia następujące kryteria:

1. Typ dokumentu musi być zdefiniowany przy użyciu jednej z metod implementacji zdefiniowanych przez W3C. Obecnie ogranicza się to do DTD XML, lecz wkrótce będzie dostępne także XML Schema. Pozostała część tego rozdziału odnosi się do „DTD”, choć inne implementacje są także możliwe.
2. DTD, które definiuje moduł musi posiadać unikatowy identyfikator stosujący się do definicji zawartych w rozdziale Reguły nazewnictwa.
3. Kiedy moduł jest zdefiniowany przy użyciu DTD XML, musi on izolować nazwy swoich encji parametrycznych poprzez użycie unikatowych prefiksów lub innych podobnych metod.
4. Definicja modułu musi zawierać słowne definicje opisujące wymagania znaczeniowe i składniowe elementów, atrybutów i/lub modelów zawartości przez nią deklarowanych.
5. Definicja modułu nie może ponownie używać żadnych nazw elementów zdefiniowanych w innych zdefiniowanych przez W3C modułach, chyba że model zawartości i semantyka tych elementów są albo identyczne z oryginalnymi, albo są ich rozszerzeniem, albo gdy ponownie użyte nazwy elementów znajdują się we własnej przestrzeni nazw (zobacz poniżej).
6. Elementy i atrybuty definicji modułu muszą być częścią przestrzeni nazw XML [XMLNAMES]. Jeśli moduł jest zdefiniowany przez organizację inną niż W3C, przestrzeń nazw NIE może być tożsama z przestrzenią nazw, w której zdefiniowane są inne moduły W3C.

3.4. Zgodność ze standardem dokumentów rodziny XHTML

Dokument rodziny XHTML zgodny ze standardem to poprawny strukturalnie egzemplarz typu dokumentu zgodnego z XHTML Host Language.

3.5. Zgodność ze standardem programów użytkownika rodziny XHTML

Program użytkownika zgodny ze standardem musi spełniać wszystkie z następujących kryteriów (jak zdefiniowano w [XHTML1]):

1. W celu zachowania zgodności z Rekomendacją XML 1.0 [XML], program użytkownika musi parsować i sprawdzać poprawność składniową dokumentu XHTML. Jeśli program użytkownika ma być walidujący, musi także sprawdzać poprawność strukturalną dokumentów biorąc pod uwagę odpowiednie DTD zgodnie z [XML].
2. Jeśli program użytkownika ma obsługiwać cechy zdefiniowane w tej specyfikacji lub wymagane przez tę specyfikację poprzez odnośniki normatywne, musi robić to w sposób zgodny z definicjami tych cech.
3. Gdy program użytkownika przetwarza dokument XHTML jako czysty XML, powinien rozpoznawać jedynie atrybuty typu ID (tj. atrybut id w większości elementów XHTML) jako identyfikatory cząstkowe.
4. Jeśli program użytkownika napotka na element, którego nie rozpoznaje, musi kontynuować przetwarzanie bezpośrednich potomków tego elementu. Jeśli zawartością elementu jest tekst, musi on być zaprezentowany użytkownikowi.
5. Jeśli program użytkownika napotka na atrybut, którego nie rozpoznaje, musi zignorować całość specyfikacji atrybutu (tj. atrybut i jego wartość).
6. Jeśli program użytkownika napotka na wartość atrybutu, której nie rozpoznaje, musi zastosować wartość domyślną atrybutu.
7. Jeśli napotka na odwołanie do encji (innej niż jedna z predefiniowanych encji), której deklaracji program użytkownika nie przetworzył (co może się zdarzyć, jeśli deklaracja jest zawarta w zewnętrznym podzbiorze, którego program użytkownika nie wczytał), odwołanie do encji powinno być renderowane jako znaki (zaczynając na znaku et i kończąc na średniku), które tworzą to odwołanie do encji.
8. Gdy program użytkownika podczas renderowania zawartości napotka znaki lub odwołania do encji znakowej, które są rozpoznane, lecz nie mogą być renderowane, powinien wyświetlić dokument w sposób dający do zrozumienia użytkownikowi, że nie zostało zastosowane normalne renderowanie.

9. Białe znaki są obsługiwane według poniższych reguł. Następujące znaki są zdefiniowane w [XML] jako białe znaki:

   • SPACJA ( )
   • TABULATOR POZIOMY (	)
   • POWRÓT KARETKI (
)
   • WYSUW WIERSZA (
)

   Procesor XML normalizuje właściwe dla różnych systemów kody końca wiersza w pojedynczy znak WYSUWU WIERSZA, który jest przekazywany do aplikacji.

   Program użytkownika musi przetworzyć białe znaki znajdujące się w danych otrzymanych od procesora XML w następujący sposób:

   • Wszystkie białe znaki otaczające elementy blokowe powinny być usunięte.
   • Komentarze są usuwane całkowicie i nie wpływają na obsługę białych znaków. Jeden biały znak po każdej stronie komentarza jest traktowany jak dwa białe znaki.
   • Gdy atrybut xml:space posiada wartość preserve, białe znaki muszą być zachowane, a w rezultacie znaki WYSUWU WIERSZA wewnątrz bloku nie mogą być zamieniane.
   • Gdy atrybut xml:space posiada wartość inną niż preserve, wtedy:
     • Wiodące i końcowe białe znaki wewnątrz elementu blokowego muszą być usunięte.
     • Znaki WYSUWU WIERSZA muszą być zamienione na jeden z następujących znaków: znak SPACJI, znak SPACJI O ZEROWEJ SZEROKOŚCI (​) lub na żaden znak (tj. usunięte). Wybór znaku wynikowego jest zależny od programu użytkownika i jest uwarunkowany przez właściwości pisma, do którego należą znaki poprzedzające i następujące po znaku WYSUWU WIERSZA.
     • Ciąg białych znaków niezawierający żadnych znaków WYSUWU WIERSZA musi być zredukowany do pojedynczego znaku SPACJI.
     • Ciąg białych znaków zawierający jeden lub więcej znaków WYSUWU WIERSZA musi być zredukowany w ten sam sposób do pojedynczego znaku WYSUWU WIERSZA.

   Biały znak w wartościach atrybutów jest przetwarzany zgodnie z [XML].

   Uwaga (o charakterze informacyjnym): By ustalić, w jaki sposób zamienić znak WYSUWU WIERSZA, program użytkownika powinien wziąć pod uwagę poniższe przypadki, w których pismo, do którego należą znaki po obu stronach WYSUWU WIERSZA przesądza o sposobie zamiany. OGÓLNE znaki pisarskie (takie jak znaki interpunkcyjne) są traktowane tak, jak znaki pisarskie po drugiej stronie znaku:

   1. Jeśli znaki poprzedzające i następujące po znaku WYSUWU WIERSZA należą do pisma, w którym znak SPACJI jest używany jako separator wyrazów, wtedy znak WYSUWU WIERSZA powinien zostać zamieniony na znak SPACJI. Przykłady takich pism to pismo łacińskie, greckie czy cyrylica.
   2. Jeśli znaki poprzedzające i następujące po znaku WYSUWU WIERSZA należą do pisma bazującego na ideogramach lub do systemu piśmienniczego, w którym nie ma separatorów wyrazów, znak WYSUWU WIERSZA powinien zostać usunięty. Przykłady takich pism czy systemów piśmienniczych to pismo chińskie i japońskie.
   3. Jeśli znaki poprzedzające i następujące po znaku WYSUWU WIERSZA należą do pisma niebazującego na ideogramach, w którym nie ma separatorów wyrazów, WYSUW WIERSZA powinien zostać zamieniony na znak SPACJI O ZEROWEJ SZEROKOŚCI (​) lub powinien zostać usunięty. Przykłady takich pism to pismo tajskie i khmerskie.
   4. Jeśli żaden z warunków od 1. do 3. nie jest prawdziwy, znak WYSUWU WIERSZA powinien zostać zamieniony na znak SPACJI.

   Raport techniczny Unicode [UNICODE] TR#24 (Nazwy pism) przyporządkowuje nazwy pism dla wszystkich znaków.

3.6. Reguły nazewnictwa

Typy dokumentów XHTML Host Language muszą stosować się do sztywnych konwencji nazewnictwa, by umożliwić oprogramowaniu i użytkownikom łatwe ustalenie relacji danego typu dokumentu do XHTML. Nazwy typów dokumentów wprowadzonych przez definicję typu dokumentu XML są definiowane poprzez formalne identyfikatory publiczne (ang. Formal Public Identifier, FPI). Pola znajdujące się wewnątrz FPI są rozdzielone przez sekwencje podwójnych ukośników (//). Poszczególne pola muszą mieć następujący skład:

1. Pierwsze pole musi mieć postać „-”, w celu wskazania prywatnie zdefiniowanego zasobu.
2. Drugie pole musi zawierać nazwę organizacji odpowiedzialnej za zarządzanie nazwanym obiektem. Nie istnieje formalny rejestr nazw tych organizacji. Każda organizacja powinna zdefiniować unikatową nazwę. Na przykład nazwą używaną przez W3C jest W3C.
3. Trzecie pole zawiera dwie konstrukcje: klasę tekstu publicznego oraz następujący po niej opis tekstu publicznego. Pierwszy leksem trzeciego pola to klasa tekstu publicznego; powinna ona stosować się do zasad Klauzuli 10.2.2.1 (Public Text Class) ISO 8879. Tylko dokumenty zgodne z XHTML Host Language powinny rozpoczynać opis tekstu publicznego od leksemu XHTML. Opis tekstu publicznego powinien zawierać łańcuch XHTML, jeśli typ dokumentu jest zgodny z XHTML Integration Set. Pole to musi zawierać także zdefiniowany przez organizację unikatowy identyfikator (np. MyML 1.0). Identyfikator ten powinien składać się z unikatowej nazwy oraz z wersji identyfikatora, która może być aktualizowana w miarę rozwijania się typu dokumentu.
4. Czwarte pole definiuje język, w którym obiekt jest opracowywany (np. EN).

Zgodnie z powyższymi regułami, nazwa typu dokumentu zgodnego z XHTML Host Language mogłaby mieć postać -//MyCompany//DTD XHTML MyML 1.0//EN. Nazwa modułu rodziny XHTML mogłaby mieć postać -//MyCompany//ELEMENTS XHTML MyElements 1.0//EN. Nazwa typu dokumentu zgodnego z XHTML Integration Set mogłaby mieć postać -//MyCompany//DTD Special Markup with XHTML//EN.

3.7. Rozwijanie modułów XHTML

Każdy moduł zdefiniowany w tej specyfikacji posiada unikatowy identyfikator stosujący się do reguł nazewnictwa zawartych w poprzednim rozdziale. Z biegiem czasu moduł może się rozwijać. Logiczną konsekwencją takiego rozwoju może być to, że niektóre aspekty modułu nie będą kompatybilne z jego poprzednią definicją. By móc upewnić się, że typy dokumentu zdefiniowane na postawie modułów zdefiniowanych w tej specyfikacji nadal działają, identyfikatory skojarzone ze zmieniającym się modułem będą aktualizowane. W szczególności, formalny identyfikator publiczny i identyfikator systemowy modułu będą zmieniane poprzez modyfikowanie identyfikatora wersji będącego częścią każdego z nich. Typy dokumentów, które chcą mieć włączoną zaktualizowaną funkcjonalność będą musiały być aktualizowane w podobny sposób.

Dodatkowo wcześniejsze wersje modułu będą nadal dostępne poprzez swoje wcześniejsze, unikatowe identyfikatory. W ten sposób typy dokumentu opracowywane przy użyciu modułów XHTML będą nadal jednolicie funkcjonowały używając swych oryginalnych definicji, nawet jeśli zestaw rozszerza się i rozwija. Podobnie egzemplarze dokumentów pisane zgodnie z takimi typami dokumentów, biorąc pod uwagę wcześniejsze definicje modułów, będą nadal poprawne strukturalnie.

Zachęca się autorów innych modułów rodziny XHTML i typów dokumentu, by przyjęli podobną strategię w celu zapewnienia ciągłego funkcjonowania typów dokumentu bazujących na tych modułach oraz egzemplarzy dokumentów opierających się na tych typach dokumentu.