Parser'lar

Parser, bir XML document'inden veri almak için kullanılan API (kütüphane)'dir. Programcılar, parser kullanarak bir XML document'inin herhangi bir yerinden bilgi alabilirler. Java'da iki tür parser vardrı DOM Parser (ki DocumentBuilder olarak geçer) ve SAX Parser. DOM Parser'ler bir document'i okuyup Document adlı bir interface döndürürler. Programcı da bu interface'i kullanarak istedği element veya attributelere tepeden başlayarak erişir. Document WWW konsorsiyumu tarafından belirlenmiş, Java'dan bağımsız C++, C# gibi dillerde de desteklenen ortak bir yapıdır. O yüzden de diğer Java class'larına göre biraz daha karmaşık ve zor kullanımı vardır. Ancak standart olması nedeniyle Java bunu desteklemektedir.

İkinci parser türü de SAX Parser'dır. SAX (Simple API for XML) demektir. Bu da konsorsiyumlarla belirlenen bir standart'tır . DOM Parser bir XML document'ini tek seferde okur ve programcıya verir. Buna karşın SAX Parser'lar bir document'i tepeden başlayarak tekte işler ve programcıya verir. Programcı sadece istediği kısımları alıp diğerlerini kaale almayabilir. DOM parser'lar bütün belgeyi tek seferde okuduğu için büyük belgelerde yavaştır. Sadece küçük bir bilginin okunması gerektiğinde SAX parserler daha iyi sonuç verir. Aslında DOM parser'larda içerisinde SAX parser'ı kullanabilmektedirler.

DOM ve SAX parser'ların standartlara uyan, başka dillerin de çalışabilmesini sağlamak için konan özellikleri Java programcıları için zorluk yaratmaktadır. O yüzden JDOM adında bir kütüphane daha bulnmaktadır. Bu, Java'nın Collection gibi bilinen yapılarıyla çalıştığı için daha kolay kullanıma sahiptir. JDOM'un yaratıcıları başka dilleri düşünülerek yapılmış bir kütüphane yerine sadece Java'yı hesaba katarak çalışan bir kütüphaneyi tercih etmektedirler. Ancak JDOM Javanın standart bir kütüphanesi değildir, ayrı olarak yüklenmelidir.

Specification-Implementation Ayrımı

Java'nın genelinde olan specification-implementation ayrımı XML API'lerinde de bulunmaktadır. Burada 'specification' API'ın tanımlaması demektir. Sadece kullanıcının bu API'dan beklediği, sadece onun kullanabileceği class'lar ve interface'lerden oluşur. Başka bir deyişle asıl işlevler tanımlanır, işlevlerin nasıl gerçekleştirildiği belirtilmez. Implementation da bu spesification'un nasıl gereçekleştirldiğidir. Bir specification bir den fazla örgüt tarafından gerçekleştirilebilir. Gerçekleştirmelerden bir tanesi daha hızlı çalışması için yapılırken bir diğeri daha az hafıza harcamak için tasarlanabilir. Ancak kullanaıcı bunlarla ilgilenmez, gerçekleştirmeyi hiç görmeden kullanır. Java'nın hemen hemen bütün kütüphaneleri böyledir. Kullanıcıyı ilgilendirmeyen class'lar kesinlikle ortada görünmez. Specification, bir çok firma, kuruluş ve kişinin bir araya gelip belirlediği bir şeydir. Sonra herkes kendi implementation'unun yapabilir. Ancak bir implementation'dan diğerine geçildiğinde kullanıcıyı bağlamaz, kodu tekrar yazmak zorunda kalmaz. XML kütüphanelri Sun,IBM ve Apache gibi bir çok kurum tarafından gerçekleştirilmiştir. Ama hepsinin kullanımı aynıdır. Programcı her biri için ayrı bir kod yazmaz. Ancak bu spesification- implementation ayrımının bir dez avantajı programcının yazacağı kodu arttırmasıdır. Örneğin XML Document'i yükleme çok basit bir şekilde yapılabilirdi :

XMLDocuemnt document=new XMLDocument();
document.load("C:\\Xmls\\Test.xml");

Oysa Java'da bu işlem

DocumentBuilderFactory factory=DocumentBuilderFactory.newInstance();
DocumentBuilder builder=factory.newDocumentBuilder();
Document document=builder.parse("C:\\Xmls\\Test.xml");

şeklinde yapılır. DocumentBuilderFactory class'ı aslında bir specification'dur. newInstance() method'u implementation'u bulur ve döndürür. Aslındda XxxDocumentBuilderFactory gibi bir class dönmektedir burada, ama programcı bunu görmez. DocumentBuilder da document build etmeye yarayan class'ı bildirmektedir. Elbette newDocumentBuilder() methodu implementation'u yapan vendor'un, adı XxxDocumentBuilder gibi bir şey olan bir class'ı döndürmektedir. Bu da programcıyı ilgilendirmez. Bazı durumlarda exception trace'lerinde 'org.apache.crimson....' şeklinde ifadeler görülebilir. Apache'nin XML kütüphanelerini kullanıyorsanız bu tip isimler gelecektir. Sun için 'com.sun..', IBM için de 'com.ibm....' gibi class'la r bulunabilir. Specification bütün bu implementation'ların aynı şekilde çalışacağını hemen hemen garantilemektedir.

XML kütüphanelerinde işleri biraz daha karıştıran şey spesification'ları belirleyen kurumların da çok çeşitli olması. Document, örneğin, WWW Consortium tarafından belirlenir ve 'org.w3c.dom' paketindedir. DOM, XML dışında HTML ve JavaScript gibi bir konuda geçerli olan bir standarttır. XML'in SAX Parser'la ilgili class ve interface'ler 'org.xml.sax' pakedindedir. SAX, XML'le ilgili ancak Java dışında dillerle (örneğin C++'la ) da implement edilebilen bir standarttır. Bunlardan başka sadece Java'da XML özgü olup bütün vendorların uyduğu spefication JAXP gibi standart da javax.xml'le baişlayan paketlerde bulunur.

Çok Karışık?

Yukarıda anlatılanlar okuyucuya çok karmaşık gelebilir. Bunların çoğu programcıyı ilgilendirmez. İlgilendiren kısımlarda da karmaşıklık fazladan biraz çaba ile giderilebilir. Bu karmaşıklık Java'nın sıkı sıkıya bağlı kaldığı bazı 'ilkeler' nedeniyledir. Birinci ilke, aynı spesification'un birdan fazla implementor tarafında gerçekleştirilebiliyor olması. Standart belirleme ayrı o standarda uyan işler yapma ayrıdır. .NET için böyle bir sorun yoktur örneğin. Bir tek şirket (Microsoft) tekbaşına XML kütüphaneleri yapar, kimseyle standart belirleme gibi sorunu yoktur. Diğerleri sadece onun yaptıklarını 'kullanır', aynı kütüphanenin daha iyisini yapmak isterlerse .NET'in kütüphanelerinden çıkmış olurlar, başkalarının onların kütüphanelerini kullanmak için kodu yeniden yazmaları gerekir. Sonuç olarak yazdıkları şey de temel kütüphanedekinden farklı olur.

Java'nın ikinci ilkesi de endüstrideki standart'lara uymasıdır. DOM Java dışında belilenmiş bir standart'tır.SAX'da öyle. Ayrıca standart tamamlanmadan Java'nın standart kütüphanelerine girmez. XPath standardı 1.0 olara tamamlandıktan sonra Java'nın kütüphanelerinde yerini alabiliyor. (Java 5.0'da ancak.). Oysa standartlar henüz bitmeden uygulanırsa, standardın değişmesi durumunda programcının yaptukları çalışmaz hale gelebilir. Microsoft'un ilk XML ve XSL kütüphaneleri standartta olmayani ya da olup da sonradan değişen bir çok özellik içermekteydi. Sonuç olarak çıkan standart ili taslaklardan çok farklı çıkınca eski kodlar kullanılmaz hale geldi.

Java'nın bir başka ilkesi bir spesification yayınlanırken bir çok vendor'un fikrinin alınması ve sonuçta herşeyin oylamayla kabul edilmesidir. JCP (Java Community Process) bunu sağlayan kuruluştur. (http://www.jcp.org) Ancak bir yenilik çoğunluk tarafından kabul edilirse Java'nın içerisinde yer alır. Bu belki Java'yı yavaşlatıcı bir etki göstermektedir ama emin adımlarla ilerlemesini sağlamaktadır aynı zamanda. Her versiyonda kütüphanenin değişmesi XML2 veya XML3 gibi versiyonların birbirimle uyumsuz olması gibi sorunlar olmaz.

Java'nın ilkeleri Java'yı karmaşıklaştırıcı bir etki yapsa da Java'yı bu güne getiren bu ilkelerden sadece biraz basitlik uğruna vazgeçilmesi doğru olmaz. Ayrıca programcını bu karmaşıklığa karşı bir önlem alması da mümkündür. Örneğin XML diye bir class yapıp şöyle bir method yazarsak :

public static Document load(String uri)
	DocumentBuilderFactory factory=DocumentBuilderFactory.newInstance();
	DocumentBuilder builder=factory.newDocumentBuilder();
	Document document=builder.parse(uri);	
	return document;
}

Bir daha da tek satırda yükleme yapabiliriz

	Document document=Xml.load("C:\\Xmls\\Test.xml");

Ne oldu? Basitleşti. Bu method Java'nın kütüphanlerinden birine konabilirdi ama konmamış. Çünkü bu hem performansı düşürücü bir yöntem (her sefer DocumentBuilderFactory ve DocumentBuilder yükleniyor ) hem de sınırlayıcı (sadece String parametresi alıyor, ya File ve URL varsa elimizde?). Basit olan ancak programaciya seçme hakkı ve tam hakimiyet vermeyen kütüphaneler uzun vadede zararlı olacaktır. Bu karmaşık ktüphane XML Document'leriyle ilgili hermen her şeyi yapabilmektedir. En acemi programcıdan en uzmanına kadar bu kütüphane kullanılmaktadır. Örneğin DocumentBuilder'ın setErrorHandler diye bir methodu var, oluşan hataları System.out yerine başka bir yerde gösterebilmeyi sağlayabilirsiniz. İlk defa öğrenirken "Ben XML okuyayım yeter!" diyenler daha sonra 'Peki şunu nasıl yapacağız?" diye sorabilmektedir. Yanıt bu karmaşık kütüphanenin içerisinde bulunmaktadır. Hem de çok basit. Java'da her şek mümnkün olduğunca basittir. Ama ondan daha basit değil!