XML, W3C himayesi altında 1996 yılında kurulan (öncülü SGML Editorial Review Board olarak bilinen) bir XML Çalışma Grubu tarafından geliştirilmiştir. XML Çalışma Grubu, Sun Microsystems'tan Jon Bosak başkanlığında W3C tarafından ayrıca örgütlenen bir XML Özel İlgi Grubunun etkin katılımıyla kuruldu. XML Çalışma Grubunun üyeleri bir ek bölümde listelenmiştir. Çalışma Grubunun W3C ile iletişimi Dan Connolly tarafından sağlanmıştır.

XML için tasarım hedefleri:

Bu belirtim, ilgili standartlarla birlikte, XML &versionOfXML;'ı anlamak ve üzerinde işlem yapacak bilgisayar programlarını oluşturmak için gerekli tüm bilgiyi sağlar (ilgili standartlar: karakterler için Unicode ve ISO/IEC 10646 , dil betimleme yaftaları için RFC 3066 , dil isimlerinin kodları için ISO 639 ve ülke isimlerinin kodları için ISO 3166 ).

XML belirtiminin bu sürümü, metnin tamamı ve yasal uyarıları aynen korunduğu takdirde özgürce dağıtılabilir.

XML belgeleri açıklamakta kullanılan terminoloji bu belirtim boyunca tanımlanmıştır. Bu çeviride, vurgulandıklarında, ZORUNLU, ÖNERİ ve SEÇİMLİK anahtar sözcükleri 'un Türkçe çevirisinde açıklandığı gibi yorumlanır. Ayrıca, aşağıdaki listede tanımlanan terimler, XML belgeleri açıklamakta kullanılan terminolojiyi oluşturmak ve bir XML işlemcinin eylemlerini açıklamakta kullanılır:

W3C'nin XML 1.0 Önergesi ilk olarak 1998'de yayınlandı ve çoğu hata raporunun belirtime yansıtılıp 2004 yılındaki üçüncü düzeltmeyle hatalardan arındırılmasına karşın, neyin iyi biçimli XML olduğu neyin olmadığı konusu değişmeden kaldı (kasten). Bu kararlılık, birlikte çalışabilirlik açısından oldukça yararlı oldu. Bununla birlikte, XML 1.0'ın karakter belirtimleri için güvendiği Unicode Standardı yerinde durmadı, gelişimini sürdürerek 2.0 sürümünden 4.0 sürümüne geldi ve gelişmeye devam ediyor. Unicode 2.0'da mevcut olmayan karakterler XML 1.0 karakter verisinde zaten kullanılabiliyordu. Yine de, bunların eleman türü adları, öznitelik isimleri, sabit öznitelik değerleri, işlem yönergelerinin hedefleri gibi XML adlarında kullanımına izin verilmiyordu. Bundan başka, XML adlarında kabul edilmesi gereken karakterler Unicode 2.0'daki tutarsızlıklar ve kusurlar yüzünden kullanılamıyordu.

Adlandırma ile ilgili gerekçeler XML 1.0'dan beri baştan sona değişti. Oysa XML 1.0, izin verilmemiş herşeyi kullanımdan kaldıran katı isim tanımlamaları yapmıştı, XML 1.1 adları (belli bir sebeple) yasaklanmamış herşeye izin verecek şekilde tasarlandı. Unicode, 4.0'dan sonra da gelişmeye devam edeceğinden isimlerde hemen her karaktere, henüz atanmamışlara bile izin vererek XML'de başka değişiklik olmaması sağlanabildi.

Ek olarak, XML 1.0 günümüzün çeşitli işletim sistemlerinin satırsonu uzlaşımların uyum sağlamaya çalışırken IBM ve IBM uyumlu büyük bilgisayarlarda kullanılan uzlaşımlarda ayrımcılık yapıyordu. Büyük bilgisayarlardaki XML belgeler yerel kabullere uygun olarak salt metin dosyalar değillerdir. Sonuç olarak, büyük bilgisayarlarda üretilen XML belgeler ya yerel satırsonu uzlaşımları ile çelişiyor ya da çözümleme öncesindeki ve üretim sonrasındaki aşamalarda gereksiz dönüşümlerle verimsizliğe sebep oluyorlardı. Veriler, dosyaları büyük sistemlerle normal bilgisayarlar arasında paylaşarak (birinden diğerine dosya kopyalama anlamında değil) saklandığı zaman düz mantıkla birlikte çalışabilirliği mümkün kılmak önem kazanır. Bu yüzden, XML 1.1 satırsonu karakterleri listesine NEL (#x85) karakterini eklemiştir. Yapmışken tam olsun diye, Unicode satır ayırma karakteri olan #x2028'de ayrıca desteklenmiştir.

Sonuçta, XML belgelerde Unicode karakterlerin standart gösterimini tanımlama konusunda öngörülebilir bir ısrar vardı. Bu yüzden, XML 1.1, XML 1.0'da çoğu yasak olan #x1 ile #x1F arasındaki denetim karakerlerine gönderime izin verir. Sağlamlık bakımından, yine de bu karakterler belgelerde doğrudan doğruya kullanılamazlar. Karakter kodlamasının saptanması konusuna sağlamlığı arttırmak için, XML 1.0 belgelerde serbestçe kullanınıma izin verilen #x7F ile #x9F arasındaki denetim karakterlerinin artık sadece karakter gönderimlerinde yer alması gerekmektedir (Boşluk karakterleri tabii ki müstesna). Geriye uyumluluk konusunda bu küçük fedakarlık önemli sayılmaz. Uygulama geliştirme arayüzleriyle olası sorunlar nedeniyle gerek doğrudan gerekse karakter gönderimi olarak #x0 karakterine hala izin verilmemektedir.

Son olarak, XML 1.1, belge oluşturucuların uyması ÖNERİlen ve belge işlemcilerenen de doğrulaması ÖNERİlen "tam normalleştirme" adı verilen bir kural kümesi tanımlamaktadır. Tamamen normalleştirilmiş belge kullanımı, Unicode dizgelerin ikilik karşılaştırmasını basitleştirerek adların, öznitelik değerlerinin ve karakterlerin özdeşlik karşılaştırmalarının doğru olarak yapılabilmesini sağlar.

Değişikliklerin iyi biçimle belge tanımını değiştirmesi sebebiyle, XML 1.0'a hata raporlarını yansıtmak yerine yeni bir XLM sürümü oluşturuldu. XML 1.0 işlemcilerinin XML adlarınad yeni karakterleri, yeni satırsonu uzlaşımlarını ve denetim karakterlerine gönderimleri içeren XML belgeleri reddetmeye devam etmeleri gerekmektedir. XML 1.0 ve XML 1.1 belgeler arasındaki ayrım, her belgenin başında bulunan XML bildirimindeki sürüm numarası bilgisiyle belirtilir.

Bir metin nesnesinin iyi biçimli bir XML belge olması için:

Bir XML belgenin belge sözdizimiyle eşleşmesi için:

Bunun bir sonucu olarak, belgedeki, kök eleman olmayan her C elemanı için, onu içeren bir P elemanı vardır. P'ye C'nin ebeveyni olarak atıf yapılırken C'ye P'nin çocuğu olarak atıf yapılır.

Bir çözümlenmiş öğe, karakter veriler yanında imlenimi de göstermekte kullanılan karakterlerden oluşan bir dizi olarak bir metin içeriğe sahiptir. Bir karakter ISO/IEC 10646 tarafından belirtildiği gibi metnin bir atomsal birimidir. Geçerli karakterler sekme, satırsonu, satırbaşı ile Unicode ve ISO/IEC 10646'nın geçerli karakterleridir. Standartların bu belge hazırlandığı sırada geçerli olan sürümlerinden bölümünde bahsedilmiştir. Bu standartların düzeltmelerinde ve eklerinde yeni karakterler eklenebilir. Sonuçta, XML işlemcilerin Kark için belirtilen aralıktaki her karakteri kabul etmeleri ZORUNLUdur.

Karakter kodlarını bit kalıpları halinde kodlayan mekanizmalar öğeden öğeye değişiklik gösterebilir. Tüm XML işlemcilerinin Unicode'un UTF-8 ve UTF-16 kodlamalarını kabul etmesi ZORUNLUdur; bu ikisini işaret eden kullanımdaki mekanizmalar ile diğer kodlamaları oyuna dahil eden mekanizmalar bölümünde açıklanmıştır.

Bu bölümde dilbilgisi içinde geniş çapta kullanılan simgeler tanımlanmaktadır.

B (boşluk karakterleri) bir veya daha fazla boşluk (#x20), sekme (#x9), satırsonu (#xA) veya satırbaşı (#xD) karakterinden oluşur.

Bir Ad, bir harf veya bir kaç noktalama iminden biri ile başlar ve isim karakterleri adı verilen, harfler, rakamlar, tire, altçizgi, ikinokta veya nokta imleri ile devam eder. xml dizgesi ile veya (('X'|'x') ('M'|'m') ('L'|'l')) ile eşleşen herhangi bir dizge ile başlayan adlar, bu belirtimin bu ve gelecek sürümlerinde standartlaşım adına ayrılıp kayıt altına alınmıştır.

Bir ad dizgeciği isim karakterlerinin bir karışımıdır.

Bir Adın ilk karakteri bir AdBaşlKark olmalı ZORUNLU ve diğer karakterleri birer AdKark olmalıdır ZORUNLU; bu mekanizma isimlerin temel aksan karakterleri ve ASCII rakamları ile başlatılmasını engellemek için kullanılır. İsimlerde ayraçlar ve ayraç olması olası karakterler dışında hemen her karaktere izin verilmiştir. Amaç zorlayıcı değil yol gösterici olmaktır, böylece henüz Unicode kodlama yapmayan yazım sistemleri XML adlarında kullanılabililir olmaktadır. İsim oluşturma konusunaku öneriler için bölümüne bakınız.

Belge yazarlarının isimlerde anlamlı sözcükleri ve doğal sözcük birleşimlerini kullanmaları; boşluk karakterlerini ve işaretleri kullanmaktan kaçınmaları önerilir. İkinokta, tire, nokta, altçizgi ve ortanokta karakterlerinin kullanımına izin verildiğine dikkat ediniz.

XML adlarının XML belgeler dışında kullanıldığı yerlerde ayraç olarak daha kullanışlı olduklarından, Unicode sembol karakterlerinden büyükçe bir gruptan başka ASCII semboller ve noktalama işaretlerinin isimlerde kullanımı yasaktır; bu grubun sağlanmasıyla, bu bağlamlarda XML isimleri olamayacak şeyler hakkında kesin garanti verilmiştir. #x037E, Yunan soru işaretine normalleştirildiğinde öğe gönderiminin anlamını değiştiren noktalı virgüle dönüştüğünden izin verilmemiştir.

Dizgesel sabitler, tırnak içine alınmış, içinde ayraç olarak tırnak imlerinin kullanılmadığı bir dizgedir. Dizgesel sabitler, dahili öğelerin (ÖğeDeğeri), öznitelik değerlerinin (ÖznitDeğeri) ve harici belirteçlerin (SistemSabiti) içeriğini belirtmekte kullanılırlar. Bir SistemSabitinin imlenim taranmaksızın çözümlenebileceğine dikkat ediniz.

Bir Metin imlenim ile karakter verisinin karışımından oluşur. İmlenim ise, başlangıç etiketleri, bitiş etiketleri, boş eleman etiketleri, öğe gönderimleri, karakter gönderimleri, açıklamalar, CDATA bölümü ayraçları, belge türü bildirimleri, işlem yönergeleri, XML bildirimleri, metin bildirimleri ve belge öğesinin tepe seviyesindeki (yani, belge elemanının ve herhangi bir başka imlenimin dış tarafındaki) boşluk karakterleriyle şekillenir.

İmlenim dışındaki tüm metin belgenin karakter verisini oluşturur.

Ve imi (&) ve açılı sol ayraç (<), bir açıklama, bir işlem yönergesi veya CDATA bölümü içinde veya birer imlenim ayracı olarak kullanılmaları dışında, birer dizge sabiti biçiminde görünmemelidirler ZORUNLU. Böyle bir durumda, ya sayısal karakter gönderimleri ya da sırasıyla & ve < dizgeleri olarak görünmelidirler ZORUNLU. Açılı sağ ayraç (>), > dizgesi kullanılarak gösterilebilirse de, uyumluluk için içerik içinde ]]> dizgesi bir CDATA bölümünün sonunu işaret etmiyorsa, dizge içinde bir karakter gönderimi veya > kullanılarak gösterilmelidir ZORUNLU.

Karakter verisi, elemanların içeriğinde, imlenim başlatma karakterini ve CDATA bölümü kapama ayracı olan ]]> dizgesini içermeyen bir karakter dizgesidir. Karakter verisi, CDATA bölümünde, CDATA bölümü kapama ayracını içermeyen bir karakter dizisidir.

Öznitelik değerlerinin tek ve çift tırnakları içermesini sağlamak için, tek tırnak karakteri ('), ' ile ve çift tırnak tarakteri ("), " ile gösterilebilir.

Açıklamalar bir belge imlenim dışında her yerde bulunabilir; ek olarak, belge türü bildiriminin içinde dilbilgisi kurallarının izin verdiği yerlerde bulunabilir. Açıklamalar belgenin karakter verisinin bir parçası değillerdir; bir XML işlemci, bir uygulamanın açıklamaların metnini almasını mümkün kılmak için açıklamaları karakter verisinin bir parçası olarak değerlendirebilir SEÇİMLİK, fakat bu gerekli değildir. Uyumluluk için, -- (çift tire) dizgesi açıklamaların içinde bulunmamalıdır ZORUNLU. Parametre öğelerine gönderimler, açıklamaların içinde tanınır olmamalıdır ZORUNLU.

Bir açıklama örneği:

Açıklama sözdiziminin, bir açıklamanın ---> ile bitmesine izin vermediğine dikkat ediniz. Bu bakımdan aşağıdaki örnek iyi biçimli değildir.

İşlem yönergeleri (İng: Processing Instruction) belgelerde uygulamaya yönelik yönergelerin bulunmasını sağlar.

İşlem yönergeleri belgenin karakter verisinin bir parçası değillerdir, ama uygulamaya aktarılmaları gerekir ZORUNLU. İşlem yönergesi, yönergenin yönlendirildiği uygulamayı betimlemekte kullanılan bir hedefle (PIHedefi) başlar. XML, xml, ve benzerleri, bu belirtimin bu veya gelecek sürümlerinin standartlaşımı için ayrılıp kayıt altına alınmıştır. İşlem yönergelerinin biçimsel bildirimi için XML Gösterim mekanizması kullanılabilir. Parametre öğelerinin gönderimleri işlem yönergeleri içinde tanınır olmamalıdır ZORUNLU.

CDATA bölümleri karakter verisinin her yerinde yer alabilir; imlenim olarak tanınmaması gereken karakterleri içeren metin bloklarını sarmalamakta kullanılır. CDATA bölümleri <![CDATA[ dizgesi ile başlar ve ]]>dizgesi ile biter:

Bir CDATA bölümünün içinde sadece CDATABitiş dizgesi imlenim olarak tanınır, dolayısıyla açılı sol ayraç ve ve-imi bölüm içinde birebir yer alabilir; < ve & biçiminde olmaları gerekmez (gerekmemeli). CDATA bölümleri birbirlerinin içinde bulunamazlar.

<greeting> ve </greeting>> etiketlerinin imlenim olarak değil, karakter verisi olarak ele alındığı bir CDATA bölümü örneği:

XML 1.1 belgelerin kullanılan XML sürümünün belirtildiği bir XML bildirimi ile başlamaları ZORUNLUdur. Örneğin, aşağıdaki eksiksiz bir XML 1.1 belgesidir, iyi biçimlidir ama geçerli değildir:

fakat bu, bir XML bildirimi içermediğinden bir XML 1.0 belgesidir:

Bir XML belgedeki imlenimin işlevi belgenin saklatım ve mantıksal yapısını tanımlamak ve öznitelik isim-değer çiftlerini belgenin mantıksal yapısıyla ilişkilendirmektir. XML, mantıksal yapının kurallarını tanımlamak ve önceden tanımlanmış saklatım birimlerinin kullanımını desteklemek için belge türü bildirimi denen bir mekanizma sağlar. Bir XML belge, bir ilişkili belge türü bildirimine sahipse ve kendi içinde ifade edilen kurallara uygunsa, geçerlidir.

Belge türü bildiriminin belgedeki ilk elemandan önce yer alması ZORUNLUdur.

XML belge türü bildirimi bir belge sınıfı için dilbilgisi sağlayan imlenim bildirimlerini içerir veya bunları işaret eder. Bu dilbilgisi, belge türü bildirimi veya DTD (Document Type Definition kısaltması) olarak bilinir. DTD, imlenim bildirimlerini içeren bir harici altkümeyi (özel bir harici öğe çeşidi) işaret edebileceği gibi imlenim bildirimlerini bir dahili altküme olarak içerebilir veya her ikisini birden yapabilir.

Bir imlenim bildirimi ya bir öznitelik listesi bildirimi ya bir öğe bildirimi ya da bir gösterim bildirimidir. Bu bildirimler, aşağıda iyi biçimlilik ve geçerlilik kurallarında açıklandığı gibi tamamen veya kısmen parametre öğelerinde yer alabilirler. Daha fazla bilgi için bölümüne bakınız.

Yalnız dikkat edin, bir iyi biçimli belge belgetürübild içinde ya bir harici altkümeyi işaret etmeli ya bir dahili bir altkümeyi içermeli veya ikisini de yapmalıdır. Hiçbirinin olmaması iyi biçimlilik için olası değildir.

İmlenim bildirimleri tamamen veya kısmen parametre öğelerinin ikame metni içinde yer alabilir. Bu belirtimdeki tek tek tanım terimlerinin (elemanBild, ÖznitListBild, vs.) bundan sonraki sözdizimi tanımları, tüm parametre öğeleri içerildikten sonraki bildirimleri tanımlayacaktır.

Parametre öğesi gönderimlerinden dizgesel sabitlerin, işlem yönergelerinin, açıklamaların ve yoksayılan şart bölümlerinin (bkz, ) içinde olanlar hariç, kalan hepsi DTD (dahili ve harici altkümeler ile harici parametre öğeleri) içinde her yerde tanınırlar (anlamlarını korurlar). Ayrıca, öğe değeri dizgesel sabitlerinde de tanınırlar. Parametre öğelerinin dahili altkümelerde kullanımı aşağıda açıklandığı gibi kısıtlanmıştır.

Dahili altküme gibi, bir BildAyr içinden gönderimde bulunulan bir harici altküme ve her harici parametre öğesi, boşluklar veya parametre öğesi gönderimleri arasına serpiştirilmiş imlenimBild tanım terimi tarafından izin verilen türlerdeki bir dizi eksiksiz imlenim bildiriminden oluşmalıdır. Harici altkümenin veya bu harici parametre öğelerinin içeriği kısmen şart bölümü oluşumu kullanılarak şartlı olarak yoksayılabilir; buna dahili altkümede izin verilmez ama dahili altkümeden atıf yapılan harici parametre öğelerinde izin verilir.

Harici altküme ve harici parametre öğeleri, dahili altkümedekilerden, parametre öğesi gönderimlerine imlenim bildirimlerinin arasında değil, içinde izin veriliyor olmasıyla da ayrıca farklıdırlar.

Belge türü bildirimine sahip bir XML belge örneği:

Sistem belirteci hello.dtd, belge için bir DTD adresi (veya bir tanım-yeri başvurusu) vermektedir.

Bildirimler bu örnekteki gibi yerel olarak da yapılabilir:

Harici ve dahili altkümelerin her ikisi de kullanılmışsa, dahili altküme, harici altkümeden önceymiş gibi ele alınmalıdır ZORUNLU. Bu, dahili altkümedeki öğe ve öznitelik listesi bildirimlerinin harici altkümedekilerden öncelikli olması demektir.

Eğer bir belge XML 1.0 olarak iyi biçimli ve geçerliyse ve karakter öncelemeleri halinde olmak dışında [#x7F-#x9F] aralığındaki denetim karakterlerini içermiyorsa basitçe sürüm numarasını değiştirerek XML 1.1 olarak da iyi biçimli ve geçerli yapılabilir.

XML işlemci tarafından uygulamaya aktarıldığından imlenim bildirimleri belge içeriğini etkileyebilir; örneğin, özniteliklerin öntanımlıları ve öğe bildirimleri. XML bildiriminin bir bileşeni olarak karşımıza çıkabilen tekbaşına belge bildirimi, belge öğesine veya parametre öğelerine harici bildirim olarak görünen bildirimlerin olup olmadığını bilgisini taşır. Bir harici imlenim bildirimi harici altkümede veya bir parametre öğesinin (dahili veya harici) içinde bulunan bir imlenim bildirimidir (geçerlilik sınaması yapmayan XML işlemciler parametre öğelerini de okumadıklarından bunlarda listeye dahildir).

Bir tekbaşına belge bildiriminde yes değeri, XML işlemciden uygulamaya aktarılan bilgiyi etkileyen hiçbir harici imlenim bildirimi olmadığı anlamına gelir. yes değeri ise böyle harici bildirimlerin olduğunu veya olabileceğini belirtir. Tek başına belge bildiriminin sadece harici bildirimlerin varlığının belirtisi olduğuna; bir belgede, harici öğelere gönderimlerin varlığının, bu öğeler dahili olarak bildirildiğinde belgenin tekbaşınalık halini etkilemeyeceğine dikkat ediniz.

Eğer hiçbir harici imlenim bildirimi yoksa, tekbaşına belge bildiriminin hiçbir anlamı yoktur. Eğer harici imlenim bildirimleri varsa fakat tekbaşına belge bildirimi yapılmamışsa değerin no olduğu varsayılır.

standalone="no" bildirimli bir XML belgesi, bazı ağ üzerinden teslimat uygulamaları tarafından talep edilmesi nedeniyle, algoritmik olarak bir tekbaşına belgeye dönüştürülebilir.

Tekbaşına belge bildirimli bir XML bildirimi örneği:

İmlenimden bağımsız olarak okunabilirliği arttırmak için XML belgeler düzenlenirken boşluk karakterleri (boşluklar, sekmeler, boş satırlar) bol bol kullanılır. XML belgenin dönüşeceği belgede böyle boşlukların istenmediği ve/veya özellikle korunmasının istendiği içerikler (şiir, kaynak kod gibi) olacaktır.

Bir XML işlemcinin imlenime ait olmayan tüm karakterleri uygulamaya aktarması ZORUNLUdur. Ayrıca, bir geçerlilik denetimi yapan XML işlemcinin bu karakterlerin eleman içeriğinde bulunan boşluk karakterlerinden olup olmadıkları konusunda da uygulamayı bilgilendirmesi ZORUNLUdur.

İçeriğindeki boşlukların korunması gereken elemanlar bunu uygulamaya, xml:space adlı özel bir öznitelikle bildirebilirler. Geçerli belgelerde, bu özniteliklerin, diğerleri gibi kullanıldıkları takdirde bildirilmeleri ZORUNLUdur. Bildirilirken, değeri bir sayısı sabit tür olarak, default ve preserve değerlerinden biri veya ikisiyle birden bildirilmelidir. Örnek:

default değeri, bu eleman için uygulamaca kabul edilen boşluk karakterleri işleme kipinin uygun olacağını; preserve değeri ise, uygulamanın boşluk karakterlerinin oluşturduğu boşlukları korumasının istendiğini belirtir. Bildirilen isteğin, elemanın içeriğindeki tüm elemanlara (onlarda ayrıca birer xml:space özniteliği bulunmadıkça) uygulanacağı varsayılır. Bu belirtim xml:space özniteliğine default ve preserve dışında anlamlı bir değer atamaz. Başka değerlerin belirtilmesi bir hatadır; XML işlemci hatayı raporlayabileceği gibi SEÇİMLİK, öznitelik belirtimini yoksayarak veya hatalı değeri uygulamaya raporlayarak hatadan kurtulabilir SEÇİMLİK. Uygulamalar hatalı değerleri reddedebilir veya yoksayabilir.

Bir belgenin kök elemanının, bu öznitelik için bir değer sağlanmadıkça veya öznitelik bir öntanımlı değerle bildirilmiş olmadıkça, uygulamanın boşluk işleme ile ilgili olarak uygulamaya hiçbir istek bildirmek zorunda olmadığı varsayılır.

XML çözümlü öğeleri genellikle, düzenleme kolaylığı bakımından satırlar halinde düzenlenmiş dosyalardan oluşur. Bu satırlar genellikle satırsonu (#xA) ve satırbaşı (#xD) karakterlerinin biri veya ikisi kullanılarak birbirlerinden ayrılırlar.

Uygulamaların görevlerini basitleştirmek için XML işlemci girdideki harici çözümlenmiş öğelerde (belge öğesini de içererek) bulunan tüm satırsonları, girdi çözümlenmeden önce, aşağıdakileri tek bir #xA karakterine dönüştürülerek normalleştirilmiş gibi davranmalıdır ZORUNLU:

#x85 ve #x2028 karakterleri bir öğenin kodlama bildirimi (varsa) okunana kadar güvenilir şekilde tanınamaz ve dönüştürülemez. Bu yüzden, bunları XML ve metin bildirimlerinde kullanmak ölümcül bir hatadır.

Belge işlemede genellikle, içeriğin yazıldığı doğal ve biçimsel dili bilmek yararlıdır. Bir XML belgedeki elemanların öznitelik değerlerinde ve içeriğinde kullanılan dili belirtmek için belgeye xml:lang isimli özel bir öznitelik yerleştirilebilir. Geçerli bir belgede bu özniteliğin, diğerleri gibi, kullanılmışsa bildirilmiş olması ZORUNLUdur. Özniteliğin değeri olarak (Dil Tanıtım Yaftaları) veya bir ardılı tarafından tanımlanmış dil belirteçlerinden biri veya boş dizge belirtilebilir.

(33'ten 38'e kadar olan tanım terimleri silindi.)

Örnek:

xml:lang tarafından belirtilen dil, belirtildiği elemana (özniteliklerinin değerleri dahil) ve içindeki tüm elemanlara (xml:lang belirtilmiş iç elemanlar hariç) uygulanır. Özellikle, B elemanını kapsayan bir A elemanındaki bir xml:lang belirtimi, B elemanındaki xml:lang özniteliğinde başka bir dil belirtmeksizin, boş değer belirterek, B elemanı için değiştirilebilir. B elemanının içeriği, sanki üstsel elemanlarında veya kendisinde hiç xml:lang belirtilmemiş gibi hiçbir dil içeriğiyle ilişkilendirilmez. Uygulamalar, hangi elemanların öznitelik değerlerinin ve hangi içerik parçalarının, belirtildiği takdirde, xml:lang ile belirtilen dile bağlı olarak ele alınacağını kendileri saptar.

xml:lang için basit bir bildirim şöyle olabilir:

Ancak, eğer uygunsa, özel öntanımlı değerler ayrıca verilebilir. İngiliz öğrenciler için Fransız şiirlerinin bir kolleksiyonu ile İngilizce olan tefsirler ve notlar xml:lang özniteliği şöyle bildirilebilir:

Aşağıdaki XML uyumlu oluşumların tanımlarına ilaveten tüm XML çözümlü öğelerinin (belge öğeleri dahil) tanımına uygun olarak tamamen normalleştirilmesi ÖNERİlir:

Yine de, tamamen normalleştirilmiş olmasa bile bir belge hala iyi biçimlidir. XML işlemcilerin belgenin tamamen normalleştirilmiş biçimde işlenmesi konusunda kullanıcıya bir seçenek sunmaları ve bunun istenip istenmediğini uygulamaya raporlamaları ÖNERİlir. Doğrulamama seçeneğinin sadece girdi metni bölümünde tanımlandığı gibi onaylı olduğu takdirde seçilmiş olması ÖNERİlir.

Tamamen normalleştirme doğrulaması, öğenin, bölümünde açıklandığı gibi dahili normalleştirmeli biçimde olduğu doğrulandıktan sonra bölümünde açıklandığı gibi aksan karakteri ile başlayan yukarıda listelenmiş uyumlu oluşumlardan hiçbiri doğrulanmayarak başarılmış olmalıdır ZORUNLU. Geçerlilik sınaması yapmayan işlemcilerin okunmayan harici öğelerin içerilmesine sebep olacak olası normalleştirmemeleri yoksayması ZORUNLUdur.

Tamamen normalleştirme doğrulanırken, bir işlemci normalleştirme özellikleri saptanamayan karakterlere (yani, işlemcinin gerçekleştiriminde kullanılan Unicode sürümünde henüz bulunmayan karakterlere) rastlarsa, işlemci, seçim kullanıcının olmak üzere, bu karakterlerin sebep olması olası normalleştirmemeleri yoksayabilir SEÇİMLİK. Bu normalleştirmemeleri yoksayma seçeneği, güvenilirlik ve güvenlik önem kazandığında uygulamalar tarafından seçilmiş olmamalıdır ÖNERİ.

XML işlemcilerin tamamen normalleştirilecek girdiyi dönüştürmemesi ZORUNLUdur. Gerek XML 1.1 gerekse XML 1.0 girdiden XML 1.1 çıktı oluşturacak XML uygulamalarının çıktının tamamen normalleştirilmiş olduğundan emin olmaları ÖNERİlir; dahili işlemler için tamamen normalleştirme gerekli değildir.

Bu bölümün amacı XML işlemcileri, XML belge oluşturucuların belgeyi gerektiği gibi normalleştirdiklerinden emin olmaya teşvik etmektir. Böylece, XML uygulamaları, Unicode'un mümkün kıldığı olası farklı dizge hecelemeler hakkında endişelenmeksizin dizgelerin özdeşlik karşılaştırmaları gibi sınamaları yapabilirler.

Öğeler Unicode kodlu olmadıklarında, eğer bunların kodlamasını işlemci dönüştürecekse, işlemcinin normalleştirme yapan bir dönüştürücü kullanması ÖNERİlir.

Boş olmayan her XML elemanının başlangıcı bir başlangıç etiketi ile imlenir.

Başlangıç ve bitiş etiketindeki Ad, elemanın türünü verir. Ad-ÖznitDeğeri çiftine elemanın öznitelik belirtimi, her çiftteki Ada öznitelik adı ve ÖznitDeğeri (' veya " ayraçları arasındaki metin) içeriğine de öznitelik değeri denir. Bir başlangıç etiketindeki veya bir boş etiketteki öznitelik belirtimlerinin sırasının önemsizliğine dikkat ediniz.

Bir başlangıç etiketi örneği:

Bir başlangıç etiketi ile başlayan her elemanın sonu, başlangıç etiketinde belirtilen eleman türünü yansıtan ismi içeren bir bitiş etiketi tarafından imlenir:

Bir bitiş etiketi örneği:

Başlangıç ve bitiş ekiketleri arasındaki metine elemanın içeriği denir:

Hiç içeriği olmayan eleman boştur. Bir boş eleman ya bir başlangıç etiketinin hemen ardına bir bitiş etiketi yerleştirerek ya da bir boş eleman etiketi ile gösterilir. Bir boş eleman etiketi özel bir biçime sahiptir:

Boş eleman etiketi EMPTY anahtar sözcüğüyle bildirilmiş olsun ya da olmasın hiçbir içeriğe sahip olmayan her eleman için kullanılabilir. Birlikte çalışabilirlik için, boş eleman etiketi sadece ve sadece EMPTY bildirimli elemanlar için kullanılmalıdır ÖNERİ.

Boş eleman örnekleri:

XML belgenin eleman yapısı, geçerlilikle ilgili amaçlara yönelik olarak, eleman türü ve öznitelik listesi bildirimleri kullanılarak kısıtlanabilir. Bir eleman türü bildirimi elemanın içeriğini kısıtlar.

Eleman türü bildirimleri çoğunlukla elemanın çocukları olan eleman türlerini kısıtlar. Seçim kullanıcının olmak üzere, bir XML işlemci, bir bildirimin hakkında hiçbir bildirimin yapılmadığı bir elemanı içermesi ama bunun bir hata olmaması durumunda bir uyarı verebilir SEÇİMLİK.

Bir eleman türü bildiriminin biçimi:

Burada Ad bildirdiği elemanın türüdür.

Eleman türü bildirimi örnekleri:

Öznitelikler isim-değer çiftlerini elemanlarla ilişkilendirmek için kullanılmalıdır. Öznitelik belirtimleri başlangıç etiketleri ve boş eleman etiketleri dışında gözükmemelidir ZORUNLU; bu nedenle, bunları eşleştirmek için bölümündeki sözdizimi tanımları kullanılır. Öznitelik listesi bildirimlerinin kullanım yerleri:

Öznitelik listesi bildirimleri ile ad, veri türü ve belli bir eleman türü ile ilişkili öznitelikler için (varsa) öntanımlı değer belirtilir:

ÖznitListBild sözdizimi tanımındaki Ad bir eleman türüdür. Seçim kullanıcının olmak üzere, bir XML işlemci, eğer bir öznitelik, bildirilmemiş bir eleman türü için bildirilmişse uyarı verebilir SEÇİMLİK, fakat bu bir hata değildir. ÖznitListBild sözdizimi tanımındaki Ad özniteliğin ismidir.

Bir eleman türü için birden fazla ÖznitListBild varsa bunların içerikleri birleştirilir. Bir eleman türünün aynı özniteliği için birden fazla bildirim varsa, ilk bildirim dışındakiler yok sayılır. Birlikte çalışabilirlik için, DTD yazarları belli bir eleman türü için en fazla bir öznitelik listesi bildirimi, bir öznitelik listesi bildirimindeki belli bir öznitelik ismi için en fazla bir öznitelik tanımı ve her öznitelik listesi bildiriminde en az bir öznitelik tanımı yapmayı tercih edebilir. Birlikte çalışabilirlik için, seçim kullanıcının olmak üzere, bir XML işlemci, bir eleman türü için birden fazla öznitelik listesi bildirimi veya bir öznitelik için birden fazla öznitelik tanımı varsa, bir uyarı verebilir SEÇİMLİK, fakat bu bir hata değildir.

Şart bölümleri belge türü bildirimi harici altkümesinin veya içerme ve yoksayma ile ilgili anahtar sözcüklere dayalı olarak DTD'nin mantıksal yapısına dahil edilen veya dışlanan harici parametre öğelerinin bölümleridir.

Dahili ve harici DTD altkümelerinde olduğu gibi, bir şart bölümü boşluk karakterlerinin arasına serpiştirilmiş olarak bir veya daha fazla tam bildirim, açıklama, işlem yönergesi veya iç içe şart bölümleri içerebilir.

Şart bölümünün anahtar sözcüğü INCLUDE ise, şart bölümü içeriği DTD'nin parçası olarak işlenmelidir ZORUNLU. Şart bölümünün anahtar sözcüğü IGNORE ise, şart bölümü içeriği DTD'nin parçası olarak işlenmemelidir ZORUNLU. Eğer INCLUDE sözcüklü bir şart bölümü daha geniş bir IGNORE sözcüklü şart bölümünün içeriğinde yer alıyorsa, hem iç hem de dıştaki şart bölümleri yoksayılmalıdır ZORUNLU. Yoksayılan bir şart bölümünün içeriği, anahtar sözcüğü izleyen "[" ile başlayıp, şart bölümünün sonuna kadar, başı "<![", sonu "]]>" olan şart bölümleri dışında kalan herşey yoksayılarak çözümlenmelidir ZORUNLU. Parametre öğesi gönderimleri bu işlemde tanınır olmamalıdır ZORUNLU.

Şart bölümünün anahtar sözcüğü bir parametre öğesi gönderimi ise, işlemci şart bölümünün içerileceğine mi yoksa yok mu sayılacağına karar vermeden önce parametre öğesinin yerine içeriği yerleştirilmelidir ZORUNLU.

Bir örnek:

Bir karakter gönderimi ISO/IEC 10646 karakter kümesinden belli bir karaktere atıf yapar; örneğin, girdi aygıtları tarafından doğrudan erişilebilir olmayan bir karakteri belirtmek için.

Eğer karakter gönderimi &#x ile başlıyor, rakamlar ve harflerden sonra bir ; ile bitiyorsa, bu gönderim karaktere ISO/IEC 10646'daki onaltılık kodu ile atıf yapıyor demektir; eğer &# ile başlıyor ve rakamlardan sonra ; ile bitiyorsa, karaktere onluk koduyla atıf yapıyor demektir.

Bir öğe gönderimi bir isimli öğenin içeriğine atıfta bulunur. Genel öğelere atıf yapmak için ve-imini (&) ve noktalı virgülü (;) ayraç olarak kullanan gönderimlerdir. Paramete öğesi gönderimleri ayraç olarak yüzde imini (%) ve noktalı virgülü (;) kullanan gönderimlerdir.

Karakter ve öğe gönderimi örnekleri:

Parametre öğesi gönderimi örneği:

Öğeler bu tanımla eşleşecek şekilde bildirilir:

Ad bir öğe gönderimini veya çözümlenmemiş öğe durumunda ENTITY veya ENTITIES özniteliğinin değerindeki öğeyi betimler. Eğer aynı öğe bir kereden fazla bildirilmişse, ilk bildirim bağlayıcıdır; seçim kullanıcının olmak üzere, bir XML işlemci eğer defalarca bildirilmiş öğeler varsa bir uyarı verebilir SEÇİMLİK.