\documentstyle[12pt,polski]{article}
\textwidth=15cm
\textheight=19cm
\author{Maria G`orecka\\Tomasz M.\ Wolniewicz}
\title{Stosowanie j`ezyk`ow narodowych w rozleg`lych systemach baz danych
na podstawie\\ X.500 Directory}
\begin{document}
\maketitle

\section{Wst`ep}
Niniejszy raport ma na celu przedstawienie wybranej problematyki
stosowania j`e\-zy\-k`ow narodowych w rozleg`lych, rozproszonych bazach danych.
 G`l`owny nacisk k`ladziemy na funcjonowanie bazy
X.500 Directory na przyk`ladzie  konkretnej
implementacji standardu, z jak`a mamy w praktyce do czynienia 
i konieczno`sci dostosowywania dzia`la`n do istniej`acych reali`ow. 

Sporo miejsca po`swi`ecamy na przedstawienie formalnych aspekt`ow standardu
X.500. Wydaje si`e nam to niezb`edne dla szczeg`o`lowego wyja`snienia sposob`ow
reprezentacji informacji w omawianej bazie. 

Cz`e`s`c przedstawionej pracy zosta`la wykonana w
ramach przygotowa`n do `la\-do\-wa\-nia polskiej bazy danych X.500 i sfinansowana
z grantu KBN nr 910/OBL.

\section{Baza X.500 i jej mi`edzynarodowa specyfika}



Terminem X.500 okre`sla si`e potocznie funkcjonuj`ac`a jako us`luga sieci
Internet, rozproszon`a baz`e danych o instytucjach i ich pracownikach.
Faktycznie X.500 jest standardem OSI, a funkcjonuj`aca us`luga jedynie jego
implementacj`a. Terminu X.500 b`edziemy u`xywa`c zar`owno w potocznym jak i w
formalnym znaczeniu, z kontekstu b`edzie jasne, o jakie znaczenie chodzi.


Jako standard X.500  definiuje
obiektow`a, rozproszon`a baz`e danych opart`a na modelu sieciowym. Pomimo, `xe
podstawowym za`lo`xeniem przy`swiecaj`acym tw`orcom standardu by`lo opracowanie
`swiatowej `"ksi`a`xki adresowej", X.500 dopuszcza przechowywanie w
bazie danych najzupe`lniej dowolnych typ`ow.

Standard X.500 zosta`l opublikowany w 1988 roku, a pod koniec roku 1994
oczekiwana jest publikacja nowej jego edycji. Zmieniony standard (nazywany
X.500 --- wersja 1993) znacznie rozszerza wersj`e z roku 1988,
zmienia si`e mi`edzy innymi spos`ob definiowania regu`l syntaktycznych
atrybut`ow, jak i sposobu przyporz`adkowywania identyfikator`ow obiektom
bazy. 

W niniejszym raporcie bazujemy na wersji z roku 1988 i jej
rozszerzeniach wprowadzonych przez implementacj`e QUIPU. Nale`xy oczekiwa`c,
`xe jeszcze przez d`lu`xszy czas dominowa`c b`ed`a implementacje tej w`la`snie wersji
standardu. Przewidujemy, ze po opublikowaniu nowej wersji niezb`edna b`edzie
konfrontacja naszych przemy`sle`n i wynik`ow z nowymi ustaleniami. 



Podstawowym za`lo`xeniem X.500 jest rozproszenie systemu i ogromny docelowy
rozmiar bazy. W pe`lni u`xyteczny system oparty o X.500 powinien posiada`c
tysi`ace w`ez`l`ow w ka`xdym kraju i w skali `swiata miliardy obiekt`ow. 

Jak wspomnieli`smy powy`xej X.500 zdefinowano przede wszystkim dla cel`ow
szeroko rozumianej informacji adresowej. Fakt ten ma istotny wp`lyw zar`owno
na sam standard, jego implementacje jak i funkcjonuj`ace systemy.
Wynika st`ad oczywi`scie konieczno`s`c takiego zapisywania danych w bazie, aby
z jednej strony by`ly czytelne dla u`xytkownik`ow z ca`lego `swiata, a z
drugiej dawa`ly p`e`ln`a informacje (z uwzgl`ednieniem poprawnej pisowni)
u`xytkownikom lokalnym. Niedoskona`lo`s`c istniej`acych implementacji
(korzystanie z ustalonych tablic kodowych) zmusza nas do stosowania
rozwi`aza`n tymczasowych.


\section{Definiowanie obiekt`ow bazy X.500}

W niniejszym rozdziale korzystamy w szerokim zakresie ze specyfikacji
standardu X.500 [CCITT]. Zajmujemy si`e jedynie modelem informacyjnym. Opis
modelu funcjonalnego zawarty jest w naszym raporcie [GW], jak r`ownie`x w
[CCITT] i [ROSE].

X.500 jest baz`a `"obiektow`a".
Obiekty (entries)  definiowane s`a w oparciu o
poj`ecie klasy. Okre`sla si`e klasy podstawowe, a nast`epnie ich podklasy.
Niezb`ednym atrybutem ka`xdego obiektu jest  {\tt objectClass},
determinuj`acy rodzin`e, do kt`orej obiekt nale`xy, a tak`xe
konieczne i opcjonalne atrybuty opisuj`ace ten obiekt.

Definicja obiekt`ow bazuje na poj`eciu dziedziczenia klas, co oznacza, `xe
klasa obiektu mo`xe zosta`c zdefiniowana jako podklasa wcze`sniej
okre`slonej.
Podklasy dziedzicz`a atrybuty swojej nadklasy wprowadzaj`ac przy tym 
w`lasne rozszerzenia. Atrybut {\tt objectClass} jest wielowarto`sciowy. 
Bardzo cz`esto stosowane jest
tworzenie nowej podklasy w postaci po`l`aczenia przekroju kilku klas
wyj`sciowych. Atrybuty obiekt`ow musz`a zachowywa`c okre`slone regu`ly syntaktyczne,
kt`ore s`a przetwarzane zgodnie z metodami dla nich okre`slonymi. 
Istotn`a cech`a X.500 Directory jest jego rozszerzalno`s`c --- na bazie
kilku wsp`olnych typ`ow obiekt`ow i atrybut`ow mog`a zosta`c zdefiniowane
nowe klasy i atrybuty.

\subsection{Poj`ecia podstawowe}
Nazewnictwo, kt`orego u`xywamy nie jest ca`lkowicie standardowe i nie zawsze
do ko`nca jednoznaczne. Poj`ecia {\em obiekt\/} u`xywamy na og`o`l na oznaczenie
obiektu `swiata fizycznego, kt`ory jest reprezentowany w bazie, termin ten
jednak pojawia si`e r`ownie`x w innym znaczeniu, gdy m`owimy o klasach i
podobnych terminach zwi`azanych z `"obiektowo`scia" bazy.

Termin {\em has`lo\/} u`xywany b`edzie na oznaczenie konkretnych pozycji w bazie
danych, a wi`ec reprezentacji obiekt`ow. Has`lo wyst`epuje  r`ownie`x w X.500 
jako atrybut obiektu (np. {\tt userPassword}), nie b`edziemy jednak tutaj 
wspomina`c o tym zastosowaniu.

Poni`xej przedstawiamy list`e najwa`xniejszych definicji poj`e`c X.500
Directory.

\begin{enumerate}
\item {\bf Baza informacyjna} (Directory Information Base --- DIB): ca`lo`s`c
informacji udost`epniona przez X.500 (zbi`or wszystkich obiekt`ow --- hase`l).


\item {\bf Drzewo informacji} (Directory Information Tree --- DIT): Hierarchia,
wed`lug kt`orej uporz`adkowana jest informacja zawarta w DIB.

\item {\bf Has`lo} (entry): w`eze`l DIT --- fragment informacji zawartej w DIB
opisuj`acy pojedynczy obiekt.

\item {\bf Has`lo podstawowe} (object entry): has`lo opisuj`ace dany dany obiekt.
Przy\-po\-rz`a\-d\-ko\-wa\-nie 
$$
\mbox{\tt obiekt}\mapsto \mbox{\tt has`lo podstawowe}
$$
stanowi bijekcj`e (odwzorowanie wzajemnie jednoznaczne) BIB na
zbi`or hase`l podstawowych.

\item {\bf Alias}: has`lo b`ed`ace odsy`laczem do has`la podstawowego. Wyst`epuje w
DIT w celu nadania obiektowi innej nazwy ni`x ta, zwi`azana z has`lem
podstawowym. (Standard 93 dopuszcza aliasy odsy`laj`ace do kolejnego aliasu,
pod warunkiem ostatecznej redukcji do has`la podstawowego).

\item {\bf Has`lo bezpo`srednio nadrz`edne} (immediately superior entry): has`lo
umiejscowione w DIT bezpo`srednio ponad has`lem rozwa`xanym.

\item {\bf Klasa obiektu} (object class): rodzina, do kt`orej nale`x`a 
obiekty o wsp`olnych cechach.

\item {\bf Atrybut} (attribute): element informacji dotycz`acy obiektu i
wyst`epuj`acy jako fragment opisu has`la.

\item {\bf Typ atrybutu} (attribute type): sk`ladowa atrybutu wskazuj`aca na
rodzaj informacji przedstawianej poprzez dany atrybut.

\item {\bf Warto`sciowanie atrybutu} (attribute value assertion --- AVA):
przypisanie typowi atrybutu warto`sci.

\item {\bf Wyr`o`xniona warto`s`c atrybutu} (distiguished value): jedna z
warto`sci przypisanych atrybutowi, decyduj`aca o unikalno`sci has`la na
danym poziomie pod\-drzewa i tworz`aca cz`e`s`c jego nazwy. 

\item {\bf Relatywna nazwa wyr`o`xniona} (Relative Distinguished Name --- RDN):
zesp`o`l (wyr`o`xnionych) warto`sci atrybut`ow tworz`acych jednoznaczn`a nazw`e na
danym poziomie podga`l`ezi drzewa. Typowo stosuje si`e RDN skladaj`ace si`e z
pojedynczych warto`sci atrybut`ow, ale dopuszczalne jest kojarzenie kilku
r`o`xnych atrybut`ow i ich warto`sci.

\item {\bf Nazwa wyr`o`xniona} (Distinguished Name --- DN): ci`ag RDN
okre\-`sla\-j`a\-cy umiejscowienie has`la w hierarchii DIT. Ci`ag pusty oznacza 
korze`n drzewa.
\end{enumerate}


\subsection {Model informacyjny bazy X.500}

X.500 Directory, podobnie jak inne aplikacje OSI, stosuje specyfikacj`e
CCITT --- ASN.1 ([ASN.1]) do opisu struktur danych,
tj. klas obiekt`ow, atrybut`ow i zbior`ow atrybut`ow.

\noindent
ASN.1 daje mo`xliwo`s`c definiowania makr, mechanizm ten pozwala 
na rozszerzenie zbioru okre`sle`n stosowanych do opisu z`lo`xonych
danych.

\noindent
Poni`xej przedstawiamy og`oln`a posta`c definicji podstawowej
infrastruktury informacyjnej X.500 za pomoc`a ASN.1.

\noindent
Klasa obiekt`ow zosta`la okre`slona przez makro {\tt OBJECT-CLASS},
w kt`orym uwzgl`e\-dnio\-no:
\begin {enumerate}
\item opcjonalne --- podanie identyfikatora obiektu danej klasy;
\item wskazanie wszystkich podklas definiowanej klasy ({\tt SUBCLASS OF});
\item podanie listy obowi`azkowych typ`ow atrybut`ow w danej klasie ({\tt MUST
CONTAIN}) oraz typ`ow atrybut`ow opcjonalnych ({\tt MAY CONTAIN}).
\end {enumerate}

\noindent
Podstawowa klasa obiekt`ow, b`ed`aca `"nadklas`a" ka`xdej innej klasy
to {\tt top} o na\-st`e\-pu\-j`a\-cej definicji:

\begin{verbatim}
Top ::=
  OBJECT-CLASS
    MUST CONTAIN {ObjectClass}
\end{verbatim}

\noindent
Przyk`ladowo definicja obiektu {\tt alias} ma posta`c:


\begin{verbatim}
alias ::=
  OBJECT-CLASS
    SUBCLASS OF top
      MUST CONTAIN {AliasedObjectName}
\end{verbatim}

\noindent
Standard definiuje oko`lo 20 podstawowych klas obiekt`ow.

\noindent
Typy atrybut`ow s`a okre`slane poprzez makro {\tt ATTRIBUTE}, 
kt`ore:

\begin {enumerate}
\item przypisuje identyfikator obiektu typowi atrybutu;
\item wskazuje lub definiuje syntaktyk`e typu atrybutu 
({\tt WITH ATTRIBUTE-SYNTAX});
\item wskazuje czy atrybut tego typu jest jednowarto`sciowy 
({\tt SINGLE VALUE}), czy mo`xe byc wielowarto`sciowy ({\tt MULTI VALUE}).

\end {enumerate}

\noindent
Atrybut {\tt ObjectClass} jest opisywany w notacji ASN.1 jako:

\begin{verbatim}
ObjectClass ::=
  ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax	
\end{verbatim}

\noindent
Brak okre`slenia {\tt SINGLE VALUE} implikuje wielowarto`sciowo`s`c
atrybutu.

\noindent
Standard definiuje oko`lo 40 podstawowych typ`ow atrybut`ow.

\noindent
Sama sk`ladnia atrybutu --- {\tt ATTRIBUTE-SYNTAX} jest tak`xe 
zdefiniowana przez odpowiednie makro, w ramach kt`orego nast`epuje:

\begin {enumerate}
\item przypisanie identyfikatora syntaksowi atrybutu;
\item wskazanie typu danych poprzez isniej`acy ju`x w ASN.1 syntaks;
\item opcjonalnie --- definicja regu`l dotycz`acych dopasowywania warto`sci 
atrybut`ow 
({\tt MATCHES FOR}); dopuszcza si`e tu trzy 
mo`xliwo`sci: r`owno`s`c ({\tt EQUALITY}), pod\-`la`n\-cuch ({\tt SUBSTRINGS}),
uporz`adkowanie ({\tt ORDERING}). Nowa wersja standardu 93 znacznie
rozbudowuje definicj`e regu`l dopasowywania.


\end {enumerate}

\noindent
Na przyk`lad:

\begin{verbatim}
telephoneNumberSyntax 
  ATTRIBUTE-SYNTAX
    PrintableString
      SIZE(1..ub-telephone-number))
    MATCHES FOR EQUALITY SUBSTRINGS
::= {attributeSyntax 12}
\end{verbatim}
Klauzula {\tt SIZE} pozwala wyspecyfikowa`c ograniczenia dotycz`ace
warto`sci atrybutu, w tym przypadku zosta`la okre`slona dopuszczalna
d`lugo`s`c `la`ncucha (ograniczenia te s`a podane w aneksie do
rekomendacji X.520: `"The Directory --- selected attribute types" jako
{\em UpperBounds}).

Standard X.500 wprowadza r`ownie`x makro {\tt ATTRIBUTE-SET}
umo`xliwiaj`ace grupowanie typ`ow atrybut`ow. Makro zawiera
klauzul`e {\tt CONTAINS}, po kt`orej wymieniane s`a typy atrybut`ow
nale`x`ace do grupy. Podstawowa definicja sk`lada si`e z 4 zbior`ow 
atrybut`ow, m.in. grupa {\tt postalAttributeSet} gromadzi atrybuty potrzebne
do opisania informacji o adresie obiektu.

\begin{verbatim}
postalAttributeSet    
  ATTRIBUTE-SET    
    CONTAINS {
      postalDeliveryOfficeName,
      postalAddress,
      postalCode,
      postalOfficeBox,
      streetAddress}
::= {attributeSet 1}    
\end{verbatim}

\noindent
Standard X.500~93 pozwala na definiowanie zbior`ow atrybut`ow w ramach
makra {\tt ATTRIBUTE}.

\vskip 4dd
Formalnie, wed`lug notacji ASN.1 atrybut has`la ma posta`c:

\begin{verbatim}
        AttributeValue ::= ANY

        AttributeType ::= OBJECT IDENTIFIER

        Attribute ::=
           SEQUENCE {
               type       AttributeType,
               values     SET OF AttributeValue}

       RelativeDistinguishedName ::=
           SET OF SEQUENCE {
               AttributeType, AttributeValue}

       RDNSequence ::=  SEQUENCE OF RelativeDistinguishedName 

       DistinguishedName ::= RDNSequence 
\end{verbatim}

Elementy bazy X.500, takie jak klasa obiektu czy atrybut, definiowane s`a 
w ASN.1 za pomoc`a typu zwanego identyfikatorem obiektu
({\tt OBJECT IDENTIFIER}), kt`ory okre`sla autorytatywnie nazwany obiekt.
Identyfikatory te  uporz`adkowane s`a r`ownie`x w struktur`e drzewa,
maj`a posta`c ci`agu nieujemnych liczb ca`lkowitych, z kt`orych ka`xda
jest etykiet`a kolejnego w`ez`la drzewa na drodze od korzenia do
bie`xacej pozycji. Postaci numerycznej opisuj`acej w`eze`l towarzyszy
na og`o`l kr`otki opis tekstowy.

Podstawowy w`eze`l drzewa identyfikator`ow obiekt`ow (root) ma trzy w`ez`ly
pod\-po\-rz`a\-dko\-wa\-ne:

\begin {itemize}
\item {\tt ccitt(0)}, administrowany przez CCITT;
\item {\tt iso(1)}, administrowany przez ISO/IEC;
\item {\tt joint-iso-ccitt(2)}, administrowany wsp`olnie przez ISO/IEC
i CCITT.
\end {itemize}

co ASN.1 opisuje nast`epuj`aco:

\begin{verbatim}
ccitt           OBJECT IDENTIFIER ::= { 0 }
iso             OBJECT IDENTIFIER ::= { 1 }
joint-iso-ccitt	OBJECT IDENTIFIER ::= { 2 }
\end{verbatim}

\noindent
Dalej np. na ga`l`ezi {\tt ccitt} zdefiniowano:

\begin{verbatim}
data            OBJECT IDENTIFIER ::= { ccitt 9 }
pss             OBJECT IDENTIFIER ::= { data  2342}
quipu           OBJECT IDENTIFIER ::= { pss 19200300 }
\end{verbatim}

System taki pozwala na jednoznaczne 
przy\-po\-rz`a\-dko\-wa\-nie identyfikator`ow i delegowanie odpowiedzialno`sci za
administrowanie podga`l`eziami drzewa identyfikator`ow w ramach organizacji
krajowych, a dalej przez administrator`ow na poziomie instytucji itp. 

Po przydzieleniu ga`l`ezi drzewa, instytucja lub kraj, ma pe`ln`a swobod`e w
definiowaniu swoich w`lasnych element`ow. Oczywi`scie lokalnie dodane
klasy (czy atrybuty) nie b`ed`a interpetowane przez u`xytkownik`ow nie
maj`acych dost`epu do w`la`sciwych definicji (dzi`eki jednoznaczno`sci nie
zachodzi jednak niebezpiecze`nstwo interpretacji fa`lszywej). W standardzie
X.500~(88) podstawowe identyfikatory rozpowszechniane s`a za pomoc`a
statycznych tablic, w wersji 93 przewiduje si`e umieszczenie definicji w
samym drzewie informacji. Takie rozwi`azanie spowoduje, `xe niezdefiniowane
obiekty nie b`ed`a si`e w og`ole pojawia`ly. 


Poni`xej przedstawiamy spos`ob realizacji okre`slenia podstawowego obiektu
bazy, jakim jest osoba, przyj`ety w konkretnej implementacji X.500
Directory --- QUIPU.
System ten sk`lada si`e z
trzech statycznych tablic definiuj`acych drzewo identyfikator`ow.

\begin {itemize}

\item Tabela {\bf oidtable.gen} zawiera podstawowe definicje.

\begin{verbatim}
ccitt:                  0
joint:                  2
data:                   ccitt.9
ds:                     joint.5
pss:                    data.2342
ucl:                    pss.19200300
attributeType:          ds.4
standardObjectClass:    ds.6
pilot:                  ucl.100
pilotAttributeType:     pilot.1
\end{verbatim}

\item Tabela {\bf oidtable.at} zawiera defincje atrybut`ow wed`lug schematu:

\noindent
{\tt nazwa[,skr`ot]: objectIdentifier : syntaks}

Syntaksy (regu`ly sk`ladniowe i zwi`azane z nimi metody translacji)
zakodowane s`a bezpo`sredno w `zr`od`lo programu, stanowi`a cz`e`s`c
biblotek ISODE.

\begin{verbatim}

commonName,cn:          attributeType.3:  CaseIgnoreString
surname,sn:             attributeType.4:  CaseIgnoreString	
description:            attributeType.13: CaseIgnoreString
telephoneNumber:        attributeType.20: TelephoneNumber
seeAlso:                attributeType.34: DN
userPassword:           attributeType.35: Password
\end{verbatim}



\item Tabela {\bf oidtable.oc} definjuje klasy ({\tt objectClass}) wed`lug schematu:

\noindent
{\tt  nazwa:objectIdentifier:atrybuty konieczne:atrybuty dopuszczalne}

\begin{verbatim}
top:        standardObjectClass.0 : : objectClass :

person:     standardObjectClass.6 : top : CN ,surname : \
            description, seeAlso, telephoneNumber, userPassword
\end{verbatim}

\end {itemize}

W implementacji QUIPU syntaksy s`a definiowane poprzez odpowiednie
struktury danych i zawieraj`a opr`ocz nazwy (pochodz`acej z tablicy
{\em oidtable.at}) adresy procedur wykonuj`acych podstawowe
operacje na tych atrybutach, tj. kodowanie, dekodowanie,
alokacje, dealokacje, wypisanie, por`ownanie. Istnieje r`ownie`x 
mo`xliwo`s`c wyspecyfikowania tu procedury odpowiedzialnej za 
realizacj`e przybli`xonego do\-pa\-so\-wy\-wa\-nia.
Inicjalizacja opisanych struktur nast`epuje poprzez wywo`lanie 
funkcji {\tt add\_attribute\_syntax}, kt`orej zasada dzia`lania
ma posta`c typow`a dla techniki programowania obiektowego
(definiuje dane i metody).


\section{Standard T.61}

Jedn`a z regu`l syntaktycznych stosowanych w X.500 jest wykorzystanie
standardu telekomunikacyjnego T.61 do kodowania wszelkich znak`ow 
diakrytycznych. 
`La`ncuchy zawieraj`ace wy`l`acznie znaki czytelne maj`a
przypisany syntaks {\tt PrintableString}, te w kt`orych dopuszcza si`e
znaki specjalne okre`sla si`e jako {\tt T61String}.
Tego typu `la`ncuch charakteryzuje si`e nag`l`owkiem w postaci
identyfikatora \{T.61\}
i zawiera, poza standardowymi znakami ASCII kody znak`ow
diakrytycznych.

Narodowe znaki specjalne z akcentami maj`a w standardzie T.61 posta`c 
dw`och bajt`ow: pierwszy to kod akcentu, drugi kod znaku podstawowego, inne 
s`a reprezentowane jako jeden bajt i wyst`epuj`a w tabeli na pozycjach 
powy`xej 127.
Bardzo istotne jest, `xe T.61 jednoznacznie koduje znaki bez wykorzystania
poj`ecia strony tabeli kodowej. O znaczeniu tego faktu wspomnimy poni`xej.

Oto fragment  tabeli kod`ow.

\input t61


\section{Przybli`xone dopasowywanie wzorc`ow}
Baza X.500 zawiera poj`ecie dopasowania przybli`xonego (approximate match). 
Jak ju`x wspomniano, definicje zasad syntaktycznych okre`slaj`a r`ownie`x 
metody dopasowywania
przybli`xonego. 

\noindent
Dla atrybut`ow typu `la`ncuchowego stosuje si`e algorytm
SOUNDEX. W za`lo`xeniu algorytm ten powinien wyszukiwa`c wzorce podobnie
brzmi`a\-ce.
Jego zasada dzia`lania opiera si`e na mechanizmie grupowania  sekwencji 
znak`ow --- s`l`ow podobnie brzmi`a\-cych w klasy. Ka`xda klasa otrzymuje
sw`oj kod, zaczynaj`acy si`e od pierwszego znaku s`l`ow, kt`ore 
reprezentuje. W celu dopasowania wielu s`l`ow musz`a one wyst`api`c
w por`ownywanym `la`ncuchu we w`la`sciwej kolejno`sci.

Powy`xsza definicja nie jest uniwersalna i wymaga dopasowania do
konkretnych j`ezyk`ow. Konieczno`s`c stosowania r`o`xnych algorytm`ow nie jest
przewidywana przez standard, tym niemniej powinna by`c zrealizowana
jako warunek sprawnego funcjonowania bazy w lokalnych warunkach.
Implementacja QUIPU pozwala w prosty spos`ob wprowadzi`c niezb`edne
rozszerzania w postaci dodatkowych procedur, do kt`orych odwo`lywa`c
si`e b`ed`a metody obs`lugi syntaks`ow.

\section{Ograniczenia p`lyn`ace ze stosowania zestaw`ow o`smiobitowych czcionek
komputerowych.}

Wiekszo`s`c aktualnie funkcjonuj`acych aplikacji komputerowych korzysta z
poj`ecia strony kodowej. W ten spos`ob u`xytkownik ustala, z jakiego zestawu
czcionek b`edzie korzysta`l. Zmiana strony kodowej powoduje wy`swiatlanie
innych symboli na wysokich miejscach (powyzej 127) tabeli kod`ow.
Bezpo`srednim efektem takiego podej`scia jest niemo`xno`s`c wy`swietlania na
jednym ekranie jednocze`snie znak`ow z r`o`xnych j`ezyk`ow. Stosowanie tabeli
kodowych jest szczeg`olnie ucia`xliwe w przypadkach niejednoznaczych
standard`ow (np. tabela Latin--2 (852) stosowana przez Microsoft i tabela
ISO8859-2) 

Zastosowanie w X.500 standardu T.61 pozwala na jednoznaczne zakodowanie
znak`ow `laci`nskich wszystkich j`ezyk`ow europejskich, problemem pozostaje
jednak ich wy`swietlanie. Oczywi`scie nic nie stoi na przeszkodzie, aby
aplikacja stosowa`la r`o`xne czcionki w ramach jednego ekranu i w ten spos`ob
by`la ca`lkowicie uniwersalna, ale nie jest to jak na razie powszechne
podej`scie. G`l`ownym powodem takiego zaniedbania jest najprawdopodobniej
fakt, ze wi`ekszo`s`c zachodnioeuropejskich j`ezyk`ow mie`sci sie w ramach
podstawowej tableli ISO8859-1.


\section{Proponowany schemat dostosowania bazy X.500 do wsp`o`lpracy z j`ezykami
narodowymi na przy\-k`la\-dzie j`ezyka polskiego. }

\subsection{Polskie modyfikacje a mi`edzynarodowy dost`ep}
Zak`ladamy, `xe w obecnej chwili typowy u`xytkownik na `swiecie ma do
dyspozycji interfejs wy`swietlaj`acy znaki zgodnie z tabel`a ISO-Latin-1.
Oznacza to, `xe nie ma dost`epu do polskich znak`ow diakrytycznych i jego
interfejs b`edzie je zast`epowa`l znakami nieczytelnymi. Uwa`xamy zatem, `xe
tymczasowo u`xytkownik spoza Polski musi bazowa`c na polskich nazwach
poddanych obraniu ze znak`ow diakrytycznych i takie w`la`snie nazwy maj`a by`c
stosowane w podstawowych atrybutach bazy X.500 Directory. 

Jednocze`snie jednak poprawna polska pisownia musi by`c w Directory 
przechowywana,
zar`owno ze wzgl`edu na przysz`lo`s`c, kiedy by`c mo`xe b`edzie  poprawnie
interpretowana, jak dla wykorzystania lokalnego w Polsce. Realizacj`e
dost`epu do w`la`sciwej pisowni powinny oferowa`c specjalnie do tego
dostosowane interfejsy u`xytkowe.
Dla wprowadzania polskich danych do bazy X.500 definiujemy specjalne
atrybuty du\-pli\-ku\-j`a\-ce w zasadzie atrybuty podstawowe, 
ale zawieraj`ace poprawne nazwy. Atrybuty b`ed`ace lokalnymi rozszerzeniami
nie b`ed`a poza polsk`a widziane (z powodu niemo`xliwo`sci zdekodowania
identyfikatr`ow je okre`slaj`acych), specjalizowane polskie DUA powinny
natomiast korzyst`ac z tych atrybut`ow w pierwszej kolejno`sci, ignoruj`ac
warto`sci atrybut`ow `"obranych".


\subsection{Polskie rozszerzenia}

Poni`xej przedstawiamy proponowane rozszerzenia, zwi`azane z 
definicj`a nowych klas obiekt`ow i atrybut`ow w celu wprowadzania
nazw polskich.

\begin {itemize}
\item Podstawowe polskie identyfikatory ({\tt oidtable.gen}).

\begin{verbatim}
nask:                   data.2602
umk:                    nask.1
polishQuipu:            umk.1
polishObjectClass:      polishQuipu.1
polishAttributeType:    polishQuipu.2
\end{verbatim}

\item Atrybuty ({\tt oidtable.at}).

\begin{verbatim}
polishCnName,plcn:       polishAttributeType.1 :caseIgnoreString
polishOName,plo:         polishAttributeType.2 :caseIgnoreString
polishOuName,plou:       polishAttributeType.3 :caseIgnoreString
polishLName,pll:         polishAttributeType.4 :caseIgnoreString
polishDescription:       polishAttributeType.5 :caseIgnoreList
polishInfo:              polishAttributeType.6 :caseIgnoreList
polishPostalAddress:     polishAttributeType.7 :PostalAddress
polishTitle:             polishAttributeType.8 :caseIgnoreString
multiLineDescription:    polishAttributeType.11:caseIgnoreList
fullOName,fullO:         polishAttributeType.12:caseIgnoreList
fullPolishOName,fullpLo: polishAttributeType.13:caseIgnoreList
fullOuName,fullOu:       polishAttributeType.14:caseIgnoreList
fullPolishOuName,fullpLo:polishAttributeType.15:caseIgnoreList
\end{verbatim}

\item Klasy ({\tt oidtable.oc}).

\begin{verbatim}
polishPerson: polishObjectClass.1 : person :\
   polishCnName :\
   polishDescription, polishPostalAddress, polishInfo,\
   polishTitle, multiLineDescription, memberOfGroup

polishOrganization: polishObjectClass.2 : organization :\
   polishOName :\
   polishDescription, polishPostalAddress,polishInfo,\
   polishLName, fullOName, fullPolishOName

polishOrganizationalUnit: polishObjectClass.3 :\
   organizationalUnit :\
   polishOuName : polishDescription, polishPostalAddress,\
   polishInfo, polishLName, fullOuName, fullPolishOuName

polishLocality: polishObjectClass.4 : locality :\
   polishLName :\
   polishDescription, polishPostalAddress, polishInfo
\end{verbatim}

\end {itemize}

Nale`xy zwr`oci`c uwag`e na potrzeb`e stosowania syntaksu
{\tt caseIgnoreList} do definicji pe`lnych nazw w j`ezyku polskim
({\tt fullPolishOName, fullCnName} itp.).
Wynika to z narzuconego przez standard ograniczenia dla 
{\tt caseIgnoreString}, kt`ory mo`xe by`c `la`ncuchem o maksymalnej
d`lugo`sci 64 znak`ow. Nietrudno, stosuj`ac kodowanie wed`lug T.61
t`e granic`e przekroczy`c, st`ad konieczno`s`c definiowania
jako {\tt caseIgnoreList}, pozwalaj`acego wprowadza`c `la`ncuch
z`lo`xony ze sk`ladowych, z kt`o\-rych ka`xda ma do 64 znak`ow.


\subsection{Zasady por`ownywania atrybut`ow}

Jedn`a z najistotniejszych funkcji wykonywanych na zbiorach danych X.500
jest przeszukiwanie.
Polskie serwery (DSA) powinny wykorzystywa`c zmodyfikowany wariant
algorytmu przybli`xonego dopasowywania wzorc`ow bi`or`acy pod uwag`e specyfik`e
polskiego j`ezyka. W chwili obecnej algorytm tem musi by`c zakodowany w
sewerze jako {\tt MatchingRule} dla odpowiedniego typu atrybutu (a
dok`ladniej syntaksu).

\subsection{Dostosowane interfejsy u`xytkownika}
Polski u`xytkownik powinien by`c wyposa`xony w zmodyfikowane interfejsy
DUA poprawnie wy`swietlaj`ace znaki z zakresu tabeli ISO-Latin-2 i
przetwarzaj`ace znaki spoza tej tabeli w spos`ob nie zaburzaj`acy wydruku (i
nie wprowadzaj`acy mylnej informacji). 

W ramach oprogramowania QUIPU
translacja odbywa si`e w modu`lach bibliotecznych, a zatem wystarczy
rozpowszechnia`c poprawione biblioteki. 
Cz`e`s`c prac zwi`azanych z implementacj`a tych funkcji 
w odpowiednich modu`lach zosta`la ju`x wykonana.

Innego podej`scia wymagaj`a interfejsy
korzystaj`ace z uproszczonej wersji pro\-to\-ko\-`lu X.500, zwanego
LDAP (Lightweight Directory Access Protocol). Protok`o`l ten zosta`l
zdefiniowany jako komplementarny w stosunku do pe`lnego DAP,
ale pozbawiony zb`ednego balastu i nastawiony na prost`a interakcj`e.
Powsta`lo wiele interfejs`ow opartych na tym protokole, jako `xe 
tworzenie ich jest mniej skomplikowane. Niestety funkcje 
interpretacji `la`ncuch`ow T.61 nie s`a wbudowane w biblioteki
LDAP.
W tym przypadku konieczne jest modyfikowanie ka`xedgo programu
u`xytkowego  oddzielnie.

Przwiewidujemy, `xe w nied`lugim czasie, w ramach prac obj`etych grantem KBN
udost`epnimy kilka zmodyfikowanych interfejs`ow. W drugiej kolejno`sci
pojawi`a si`e interfejsy ukierunkowane na polskie atrybuty w zakresie
przeszukiwania bazy. 

\section*{Bibliografia}
\begin{itemize}
\setlength{\labelwidth}{15mm}
\setlength{\itemindent}{5mm}
\def\makelabel#1{\hbox to \labelwidth{[#1]\hfill}}


\item [X500] Data Communication Networks: Directory, Recommendations X500-X.521,
CCITT, Fascile VIII.8 of Blue Book.

\item [ASN1] D. Steedman, ASN.1 The Tutorial and Reference, 1990.

\item [GW] Maria G`orecka, Tomasz M. Wolniewicz, Efektywno`s`c rozproszonych 
baz danych na podstawie implementacji X.500 Directory, 1994.

\item [ROSE] Marshall T. Rose, The Little Black Book: Mail Bounding with OSI 
Directory Services, Prentice Hall, 1992.
\end{itemize}
\end{document}
