Főoldal | Könyvlista | Gyorskereső

Átmenetileg a rendelés és szállítás szünetel
Hatékony XML - 50 bevált módszer XML adatszerkezetek megvalósítására

Hatékony XML

50 bevált módszer XML adatszerkezetek megvalósítására

Eliotte Rusty Harold:
Hatékony XML
50 bevált módszer XML adatszerkezetek megvalósítására

Megjelenés: 2006
Kiskapu Kiadó
288 oldal, bolti ár: 4980,- Ft

Internetes ár (-5%): 4731,- Ft

db

A könyv ismertetése

Vissza a lap tetejére | A könyv tartalomjegyzéke

Eliotte Rusty Harold:
Hatékony XML

Erre a könyvre azoknak az XML-fejlesztőknek van szüksége, akik hatékonyabbá szeretnének válni. Megtanulhatjuk, milyen eszközöket és mikor kell alkalmazni ahhoz, hogy világos, bővíthető, karbantartható és stabil XML kódot írjunk.

  • Hogyan írjunk a névtérelőtagoktól független DTD-ket?
  • Mi az, amit a nyelvi elemzők megbízhatóan jelentenek, és mi az, amit nem?
  • Melyik sémanyelv a legmegfelelőbb egy adott munkához?
  • Milyen API-t használjunk, hogy a legnagyobb sebességet és a legkisebb méretet érjük el?
  • Mit tehetünk a DTD-k, illetve a sémák gyors és megbízható eléréséért anélkül, hogy csökkenne a dokumentum hordozhatósága?
  • Lehet, hogy az XML túl terjengős az adott alkalmazáshoz?

Elliotte Rusty Harold 50 hasznos alapszabályt ír le, a valós életből merített példák alapján. Magával ragadó, könnyen érthető stílusban mutatja be, hogyan lehet fejlesztési időt nyerni, és egyúttal jobb XML kódot készíteni.

Bevezető

A Hatékony XML-ről írták

„A könyv az XML fortélyainak kitűnő gyűjteménye; minden XML-t használó fejlesztő számára nélkülözhetetlen olvasmány. Segítségével elkerülhetjük a gyakori buktatókat, és biztosíthatjuk, hogy az általunk készített XML alkalmazások a lehető legtovább jól használhatók és együttműködésre képesek maradjanak.”

– Edd Dumbill, az XML.com szerkesztőségvezetője és az XML Europe programelnöke

„Az XML-lel kapcsolatos hasznos tanácsok és eljárások gyűjteménye. Érdemes forgatni XML alkalmazások fejlesztése előtt, közben és után.”

– Sean McGrath technológiai vezető, Propylon

„Az XML számos fortélyát tartalmazó könyv, amelyet izgalommal vártunk.”

– Akmal B. Chaudri szerkesztő, IBM developerWorks

„Az ötven olvasmányos szabály az XML számos kérdésével foglalkozik a jelölés hatékony használatától kezdve annak meghatározásáig, hogy melyik feladathoz melyik sémanyelv a legalkalmasabb. Elliotte Rusty Harold időnként ellentmondásos, de mindig lényegre törő könyve az XML használatának azon szabályait tartalmazza, amelyeket az XML minden felhasználójának és alkalmazójának ismernie kell.”

– Michael Rys Ph.D., programvezető, SQL Server XML Technologies, Microsoft Corportation

„Az Effective XML kiváló könyv, és tökéletes az időzítése. Végre egy olyan XML könyv, amelyet mindenkinek el kell olvasnia! Az Effective XML az XML fortélyok és a megbízható tanácsok forrása. Mindegy, hogy az elejétől a végéig vagy véletlenszerűen, fejezetenként olvassuk a könyvet, a világos stílus és a hozzáértő tanácsok megvilágosítanak, szórakoztatnak, oktatnak, és végül még a legszakavatottabb XML-fejlesztő hatékonyságát is javítják. Csak azt mondhatom, amit a munkatársaimnak és a vásárlóimnak is: erre a könyvre mindenkinek szüksége van!”

– Michael Brundage műszaki vezető, XML Query Processing, Microsoft WebdData XML csapat

„Ez a könyv remek rálátást biztosít minden XML-szoftverfejlesztőnek, függetlenül attól, hogy a szoftver egy egyszerű, adott alkalmazáshoz írt XML-szerkesztő vagy teljesW3C XML sémanyelv-érvényesítő. Mr. Harold minden témával foglalkozik, a szaknyelv rendkívül fontos, magas szintű tárgyalásától kezdve a szintaktikailag elemzett XML csomópontokig. A jelenleg elérhető XML-rokon szoftvertermékek kimerítő kutatáson alapuló összehasonlítása és az XML eljárások közötti választás alapvető követelményeinek bemutatása jól szemléltetik, mennyire átfogó a könyv.”

– Cliff Binstok, a The XML Schema Complete Reference című könyv szerzője

Előszó

Az XML alapjainak elsajátítása egy hétbe telhet egy programozónak, de egy egész életre szükség lehet annak megtanulásához, hogy miként használjuk hatékonyan az XML-t. Noha számos olyan könyv íródott, amely az XML nyelvtanát tanítja meg a fejlesztőknek, ez a könyv az első, amely arra összpontosít, hogy hogyan kell jól használni az XML-t. Ez a könyv nem oktatókönyv; nem tanulhatjuk meg belőle, hogy mik azok a címkék és hogy miként írjunk DTD-t (Document Type Definition – dokumentumtípus-meghatározás). Feltételezzük, hogy az olvasó már ismeri ezeket. Ehelyett a könyv elárulja, hogy miként lehet hatékonyan alkalmazni ezeket az eszközöket (és talán ugyanolyan fontos, hogy mikor ne használjuk azokat).

Ez a könyv közvetlenül a szerző XML-hez kötődő oktatói és írói tapasztalataiból táplálkozik. Az elmúlt öt évben számos könyvet írt és számos előadássorozatot tartott az XML-ről, miközben egyre inkább tapasztalta, hogy a hallgatóság már ismeri az XML alapjait. Tudják, mit jelent az, hogy címke, hogyan lehet a dokumentumokat egy DTD alapján érvényesíteni, továbbá, hogy miként lehet átalakítani az XSLT (Extensible Stylesheet Language Transformations – bővíthető stíluslapnyelv-átalakítások) stíluslappal rendelkező dokumentumokat. Már megfelelőképpen elmagyarázták nekik, hogy mi az az XML, és miért érdemes használni. Meglehetősen jól ismerik a nyelvtant és az XML-t támogató technológiákat. Annak ellenére, hogy a legtöbb fejlesztő tudja, hogy mi az a CDATA szakasz, nem tudják pontosan, hogy mire kell használni. A programozók tudják, hogyan kell jellemző- és gyermekcsomópontokat adni az elemekhez, mégsem teljesen világos számukra, hogy melyik mikor használatos. A programozók ugyan ismerik a séma fogalmát, de nem tudják, melyik sémanyelvet kell választani.

Mivel az XML az új szoftverrendszerek sarkalatos alapjává vált, egyre fontosabb, hogy új kérdéseket tegyünk fel: nem csak az a kérdés, hogy mi az XML, hanem az is, hogy miként használjuk hatékonyan. Mely módszerek működnek, és melyek nem? Kevésbé magától értetődő, hogy melyek azok a módszerek, amelyek elsőre működőképesnek tűnnek, a rendszer további fejlesztésekor azonban nem méretezhetők. Amikor a szerző az egyetemen programozást tanít, legelőször azt mondja el a hallgatóknak, hogy nem elég olyan programokat írni, amelyek lefordíthatók és a kívánt eredményt adják. Ugyanolyan fontos (sőt fontosabb), hogy bővíthető, átlátható és karbantartható kódot írjunk. Az XML segítségével teherbíró, bővíthető, karbantartható és átlátható rendszereket lehet létrehozni, ugyanakkor egy sereg nehezen fenntartható, átláthatatlan, sérülékeny, zárt kódot is készíthetünk. Eric Clapton örökérvényű szavaival élve: „Attól függ, hogyan használod.”

Az XML nem programozási nyelv, hanem jelölőnyelv, de sok programozó sikerrel használja. Korábban is léteztek jelölőnyelvek, de az XML messze a legnépszerűbb a fejlesztők körében. A jelölőnyelvek újdonsága és ismeretlensége azonban azt eredményezi, hogy a fejlesztők kevésbé hatékonyan használják, mint lehetne. Sok programozó van, aki olyan rendszereket tákol össze, amelyek működőképesek, de nem olyan stabilak, bővíthetők vagy hordozhatók, mint amennyire az XML lehetővé tenné. Ez nem meglepő: az XML-lel dolgozó programozók úttörők, akik új területeket fedeznek fel, új távlatokat nyitnak a szoftverrendszerek világában, és olyan dolgokat visznek véghez, amelyek még néhány évvel ezelőtt sem lettek volna könnyen kivitelezhetők. Nem kevés XML-úttörő azonban nyilakkal a hátában tért vissza a határról.

Öt évvel azután, hogy az XML először megjelent a világban, kezd körvonalazódni néhány minta, illetve ellenminta az XML alkalmazások helyes tervezésére vonatkozóan. Az új terület felfedezése közben az XML közösségében mindenki vétett hibákat, élen e sorok szerzőjével. Mindazonáltal tanultunk a hibákból, és hozzáláttunk néhány alapelv kidolgozásához, amelyek segítségével az utánunk következők elkerülhetik az általunk elkövetett hibákat. Ideje figyelmeztető táblákat állítani az út mentén. Nem biztos, hogy azt mondjuk „Itt sárkányok vannak”, de azt legalábbis mondhatjuk, hogy „Ez az út kicsit rázósabb, mint amilyennek elsőre tűnik, és igazából jobb lenne balra menni, ahol egy valamivel kevésbé szembetűnő, de sokkal simább ösvény található.”

A könyv négy részre tagolódik, az XML legalsóbb rétegétől kezdve fokozatosan a magasabb szintek felé haladva.

Az 1. rész az XML nyelvtanát tárgyalja, az XML azon vonatkozásait, amelyek nem igazán vannak hatással az XML dokumentumok információtartalmára, de nagy mértékben befolyásolhatják, hogy a dokumentumokat mennyire könnyű vagy nehéz szerkeszteni és feldolgozni.

A 2. rész az XML szerkezeteket tekinti át – az XML dokumentumokban szereplő információ általános elrendezését és magyarázatát.

A 3. rész az XML-nek a C++-szal, a C#-tel, a Javával, a Pythonnal és a Perllel, illetve az ezekhez hasonló nyelvekkel történő feldolgozásához elérhető különböző módszereket és API-kat (Application Programming Interface – alkalmazásprogramozási felület) tárgyalja, valamint az XML-elemekhez rendelhető helyi jelentést.

A 4. rész az XML dokumentumok köré épülő rendszerek hatékony eljárásait fedezi fel ahelyett, hogy önmagukban nézné az egyes dokumentumokat.

Annak ellenére, hogy a szerző a fent leírt módon szerkesztette a könyvet, lényegében bármelyik fejezetnél kezdhetjük. Ez a könyv kiváló WC-olvasmány. Érdemes először elolvasni a bevezetőt, ahol számos olyan, a könyvben használt kulcskifejezést határozunk meg, amelyeket gyakran rosszul használnak, vagy összetévesztenek valamivel. A bevezető után azonban tetszés szerint választhatunk a témák közül, ahogy az érdeklődésünk és a szükség diktálja. A szerző bőségesen alkalmazza a kereszthivatkozásokat a könyv során, hogy más utakra tereljen bennünket, amelyek érdekelhetnek.

Ez a könyv remélhetőleg a kezdet és nem a vég. Az XML még mindig gyerekcipőben jár, és még sok mindent kell felfedezni, illetve feltalálni. Könnyen lehet, hogy valaki saját szabályokat dolgoz ki. A szerző örömmel fogadná ezeket. Az is lehet, hogy valakinek kifogása van az itt szereplő elvek némelyikével szemben. A szerző ezekről is szívesen hallana. Az xml-dev levelezési listán az itt fellelhető irányelvek jó részét már megvitatták, és ez valószínűleg a továbbiakban is így lesz. Ha valakit érdekelnek a könyvben felmerülő kérdésekről folytatott eszmecserék, érdemes feliratkoznia, és részt vennie ezekben. A http://lists.xml.org címen minden részlet megtalálható. Ha viszont valaki nyilvánvaló hibát észlel a könyvben (az ID jellemző után nincs záró idézőjel, a „macska” szót elgépeltük), az elharo@metalab.unc.edu címen közvetlenül a szerzőnek írhat. A könyv írója által fenntartott http://cafeconleche.org/books/effectivexml weboldalon megtalálható a könyv ismert hibáinak jegyzéke és az esetleges frissítések.

Végül reméljük, hogy ez a könyv hatékonyabbá és élvezetesebbé teszi az XML használatát.

Bevezetés

Ahogy azt az előszóban kijelentettem, ez se nem bevezető könyv, se nem XML oktatókönyv. Feltételezzük, hogy az olvasó ismeri az XML dokumentumok alapvető szerkezetét, vagyis a szöveget tartalmazó elemeket, tudja hogyan kell rávenni egy szövegelemzőt, hogy a választott nyelven olvasson egy adott XML dokumentumot, hogy szükség szerint illeszthetünk stíluslapokat a dokumentumokhoz és így tovább.

Az elmúlt néhány év megfigyelései azonban azt mutatják, hogy bizonyos szavakhoz és kifejezésekhez többféle jelentés társul, és gyakran következetlenül használják azokat. Ez néha csupán összezavarja az embereket, időnként azonban komoly feldolgozási hibákhoz vezet. Ezek némelyikét azok a szerzők és oktatók (kínos módon alkalmanként e sorok írója is) okozzák, akik nem elég megfontoltak az olyan szavak használatakor, mint az elem és a címke. A zavar egy részét viszont a W3C XML munkacsoportjai okozzák, akik gyakran nem elég következetesek egymás között, vagy akár egy adott leíráson belül. Mielőtt továbblépnénk a részletes pontokra, érdemes időt szánni arra, hogy körültekintően meghatározzuk a kifejezéseket, és felismerjük azokat a területeket, ahol nyilvánvalóan eltérnek a vélemények a gyakori szakkifejezések jelentésével kapcsolatban.

Ennek érdekében elkészítettem az alábbi listát, amely a leggyakrabban összetévesztett XML kifejezéseket tartalmazza:

Elem és címke

Jellemző és jellemzőérték

Egyed és egyedhivatkozás

Egyedhivatkozás és karakterhivatkozás

Gyermekek, gyermekelemek és tartalom

Szöveg, karakteradat és jelölés

Névtér, névtérnév és névtér-URI (Uniform Resource Identifier – egységes erőforrásazonosító)

XML dokumentum és XML fájl

XML alkalmazás és XML szoftver

Jólformált és érvényes

DTD és DOCTYPE

XML-bevezetés és feldolgozási utasítás

Karakterkészlet és karakterkódolás

URI, URI hivatkozás és IRI (Internationalized Resource Identifier – nemzetközi erőforrás-azonosító)

Séma és a W3C XML sémanyelv

Ha a fenti kifejezéseket összekeverjük egymással, az gyakran félreértésekhez vezet a különböző API-k és eszközök működésének kérdésében. Ha például azt hisszük, hogy egy karakterhivatkozás egyedhivatkozás, bizonyára csodálkozunk majd, hogy a SAX szövegelemző miért nem hívja meg soha a startEntity eljárást a dokumentumok karakterhivatkozásainál. Ha ezzel kapcsolatban kérdést teszünk fel egy levelezőlistán, lehet, hogy a kérdést nem úgy fogalmazzuk meg, hogy mások is megértsék. Még az is előfordulhat, hogy több órát töltünk egy teszt körültekintő kidolgozásával, és hibajelentést írunk egy olyan szolgáltatásról, ami pontosan úgy működik, ahogy kell.

Amikor elég alaposak vagyunk ahhoz, hogy pontosan kifejezzük, amit szeretnénk, számos látszólag nehéz kérdés megoldása szinte nyilvánvalóvá válik. Tehát rajtunk múlik, hogy körültekintően meghatározzuk a kifejezéseket.

Elem és címke

Az elemek nem címkék és a címkék nem elemek. Az elemek elején nyitó címke áll, utána valamilyen tartalom, a végén pedig záró címke. A címkék az elemeket határolják. Az elemek részei, de ők maguk nem elemek, ahogy egy darab kenyér sem szendvics. Ezek a címkék olyanok, mint a kenyérszeletek. Az elem az egész szendvics, amely kenyérből, mustárból, majonézből, illetve húsból, sajtból áll. A címkék csak a kenyér. A <Headline> például egy nyitó címke. A </Headline> záró címke. A <Headline>A tömeg hallja Beth kuncogását</Headline> egy teljes elem. Az elemek tartalmazhatnak további elemeket, a címkék azonban nem tartalmazhatnak más címkéket.

Egy egyszerű üreselem-címke azonban képviselhet egy egész elemet. A <Headline> például egyszerre fejléccímke és fejlécelem. Ez azonban különleges eset, mivel jelentését tekintve az üreselem-címke teljesen egyenértékű a <Headline></Headline> kétcímkés változattal, és a legtöbb API nem jelzi majd, hogy a két alak közül valójában melyik szerepel a dokumentumban.

Röviden, az XML dokumentumok szerkezetét az egymásba ágyazott elemek alkotják. Az egyes elemeket címkék határolják.

Jellemző és jellemzőérték

A jellemző egy elem tulajdonsága. Névvel és értékkel rendelkezik, és rendszerint az elem nyitó címkéjének része. (A DTD-ben alapértékként is meg lehet adni.) Vegyük például az alábbi elemet:

<Headline page="10">Crowd Hears Beth Giggle</Headline>

A fejlécelem egy 10 értékkel ellátott page (oldal) tulajdonsággal rendelkezik. A jellemzőben a név és az érték egyaránt szerepel. A jellemzőérték egyszerűen a 10 karakterlánc. A jellemzőérték idézőjelek és gondolatjelek között is állhat; nem fontos, hogy melyik jelet használjuk. Az alábbi elem pontosan ugyanaz, mint az előző:

<Headline page='10'>Crowd Hears Beth Giggle</Headline>

Ha egy elem több jellemzővel rendelkezik, nem fontos a sorrendjük. Az alábbi két elem egyenértékű:

<Headline id="A3" page="10">Crowd Hears Beth Giggle</Headline>

<Headline page="10" id="A3">Crowd Hears Beth Giggle</Headline>

A szövegelemzők nem mondják meg, hogy melyik jellemző szerepel először. Ha a sorrend lényeges, a jellemzők helyett gyermekelemeket kell alkalmazni:

<Headline>

<id>A3</id> <page>10</page>

Crowd Hears Beth Giggle

</Headline>

Ez nem igazán kifejezésbeli kavarodás, de néhány technológia (különösen a W3C XML sémanyelv) az utóbbi időben elég nagy gondot okoz magának azzal, hogy a jellemzőket és a gyermekelemeket megpróbálja egyazon dolog különböző változataiként kezelni, ugyanis nem azok. A sorrend csak egy a gyermekelemek és a jellemzők több különbsége közül. További lényeges különbség a típus, a szabványosítás és a részszerkezet megjelenítésének képessége, illetve ezen képesség hiánya.

Egyed és egyedhivatkozás

Az egyed (entity) olyan tároló elem, amely az XML dokumentumok egy részét tartalmazza. Ez a tároló elem lehet fájl, adatbázis-bejegyzés, memóriaobjektum, hálózati kiszolgáló által visszaadott bájtfolyam vagy más egyéb. Tartalmazhatja a teljes XML dokumentumot, illetve csupán néhány elemet vagy bevezetést (deklarációt). Az egyedhivatkozások ezekre az egyedekre mutatnak. Kétféle egyedhivatkozás létezik: általános egyedhivatkozás és paraméteregyed-hivatkozás. Az általános egyedhivatkozás „&” karakterrel kezdődik, például &amp; vagy &chapter1;. Ezek rendszerint a példánydokumentumban jelennek meg. A chapter1 egyedet például a következőképpen határozhatjuk meg a DTD-ben:

<!ENTITY SYSTEM chapter1 "http://www.example.com/chapter1.xml">

A dokumentumban pedig így hivatkozhatunk rá:

<book>

&chapter1;

...

</book>

A &chapter1; egyedhivatkozás. A http://www.example.com/chapter1.xml címen található dokumentum tényleges tartalma egy egyed. Összefüggnek egymással, de a kettő nem ugyanaz.

A paraméteregyedek és a paraméteregyed-hivatkozások ugyanezt az elvet követik. Az a különbség, hogy a paraméteregyedek példánydokumentum-töredékek helyett DTD-töredékeket tartalmaznak, és a paraméteregyed-hivatkozások „és” (&) jel helyett százalékjellel (%) kezdődnek. Az egyedhivatkozás ennek ellenére továbbra is a tényleges egyed helyén áll, és arra mutat.

Az XML API-k kissé zavartak abban a kérdésben, hogy egyedeket vagy egyedhivatkozásokat jelezzenek, illetve mindkettőt vagy egyiket sem. Némelyik, például az XOM egyszerűen a megfelelő egyedekre cseréli az összes egyedhivatkozást, és nem jelzi, hogy bármi történt volna. Mások, például a JDOM csak a feloldatlan egyedeket jelenti. Megint mások, mint a DOM és a SAX az egyedeket és az egyedhivatkozásokat is képesek jelezni, igaz, ez gyakran a felhasználó választásán és a rendelkezésre álló szövegelemzőn múlik. Ezen kívül az öt előre meghatározott egyedhivatkozást (&amp;, &lt;, &gt;, &quot; és &apos;) nem jelzik.

Egyedhivatkozás és karakterhivatkozás

Nem minden egyedhivatkozás, ami & jellel kezdődik. Az egyedhivatkozások csak nevesített egyedeknél használhatók, ezek közé tartozik az öt előre meghatározott egyedhivatkozás, például az &lt; és minden olyan egyed, amelyet a DTD-ben az ENTITY bevezetéssel határozunk meg, csakúgy, mint a fenti példában szereplő chapter1;.

Ezzel ellentétben a karakterhivatkozások nem nevet, hanem egy tizenhatos vagy tízes számrendszerbeli Unicode értéket használnak ahhoz, hogy egy adott karakterre hivatkozzanak. Ezek mindig egyetlen karakterre mutatnak, és soha nem karaktercsoportra. A &#xA0; például tizenhatos számrendszerbeli karakterhivatkozás, amely a nem törhető szóköz karakterre hivatkozik, a &#160 pedig ugyanerre a karakterre mutató tízes számrendszerbeli karakterhivatkozás. Az XHTML-beli &nbsp a karakterre mutató egyedhivatkozás.

Még azok az API-k sem jelzik szinte soha a karakterhivatkozásokat, amelyek megbízhatóan jeleznek minden egyedhivatkozást. Ehelyett a szövegelemző csendben a környező szövegbe olvasztja a hivatkozott karaktereket. A kódnak soha nem szabad arra támaszkodnia, hogy egy karaktert begépeltek-e vagy karakterhivatkozásból származik. Az esetek döntő többségében arra sem szabad építenie, hogy egy karakter egyedhivatkozásból származik-e.

Gyermekek, gyermekelemek és tartalom

Az elemek tartalma a nyitó címke és a záró címke között álló rész. Vegyük például ezt a DocBook para elemet:

<para>

Amennyire ismert, a Fibonacci-sorozatokat először Leonardo Pisano

fedezte fel, körülbelül időszámításunk szerint 1200-ban.

Leonardo a <!-- Scritti di Leonardo Pisano. Róma,

Baldassarre, 1857. I. kötet, 283-284. oldal Fibonacci,

Leonardo. --> <quote lang="la"><foreignphrase>Quot paria

coniculorum in uno anno ex uno pario germinatur? </foreign

phrase></quote>, kérdést próbálta megválaszolni, ami magyarul

annyit tesz: <quote>Egy év alatt hány pár nyúl születik

egy pártól?</quote> Leonardo problémájának megoldásához először

becslésként mondjuk, hogy a nyulak terhessége egy hónapig tart,

és először egyhónapos korukban képesek párosodni, tehát minden nőstény

kéthónapos korában szüli meg az első almot. Ezután az egyszerűség

kedvéért feltételezzük, hogy minden alomban pontosan egy hím és

egy nőstény születik.

</para>

A fenti para elem tartalma némi szöveg, térközökkel, egy megjegyzés, további szöveg, egy quote gyermekelem, még több egyszerű szöveg, egy újabb quote gyermekelem, további egyszerű szöveg, az &rsquo egyedhivatkozás, végül még több szöveg. Mindez együtt a para elem tartalma, beleértve a gyermekelemek, vagyis a quote összes tartalmát.

A para elem két gyermekelemmel rendelkezik – mindkettő neve quote –, de nem ezek az egyedüli gyermekei. Az elem egy megjegyzést, számos karakteradatot és egy egyedhivatkozást is tartalmaz. Ezek szintén a para elem gyermekeinek számítanak, bár a különböző API-k és rendszerek eltérő módon valósítják meg ezeket, és a szöveggyermekek száma is változó. Az egyik véglet az, hogy minden külön karakter külön gyermek lehet. A másik véglet az, hogy az egyes csomópontokban a lehető legnagyobb folytonos szövegfolyam szerepel az egyedhivatkozások feloldása után, így a para elem pontosan négy szövegcsomópont-gyermekkel rendelkezik.

Ezzel ellentétben a foreignphrase elem és a quote elemeken belül szereplő többi tartalom nem a para elem gyermekei, annak ellenére, hogy annak leszármazottai.

Legtöbbször azért tévesztik össze a gyermekeket a gyermekelemekkel, mert megfeledkeznek a vegyes tartalom lehetőségéről. Mindemellett a gyermekek és a gyermekelemek közötti különbség akkor is fontos lehet, amikor a dokumentum inkább adatsorszerű szerkezettel rendelkezik. Vegyük például a következő presentation elemet:

<presentation>

<title>DOM</title>

<date>2002. november 21., csütörtök</date>

<host>Software Development 2002 East</host>

<copyright>2000-2002 Elliotte Rusty Harold</copyright>

<last_modified>2002. november 26.</last_modified>

<author_name>Elliotte Rusty Harold</author_name>

<author_url>http://www.elharo.com/</author_url>

<author_email>elharo@metalab.unc.edu</author_email>

<abstract>Elliotte Rusty Harold DOM oktatóanyaga</abstract>

</presentation>

Úgy tűnhet, hogy az elem kizárólag gyermekelemekkel rendelkezik. Ha azonban megszámoljuk a gyermekcsomópontokat, a térközöket is bele kell számítani. Legalább tíz olyan gyermekcsomópont van, amely csak szóközöket tartalmaz. Mi a helyzet továbbá a title, a date, a host és az ezekhez hasonló elemekkel? Mindegyikük rendelkezik egy olyan gyermekcsomóponttal, amely karakteradatokat tartalmaz, de gyermekelemek nincsenek. A tanulság az, hogy nem csak az elemek lehetnek gyermekek.

Szöveg, karakteradat és jelölés

Az XML dokumentumok szövegből állnak – soha nem találunk bennük olyat, ami nem szöveg. Ez a szöveg két elkülönített halmazra osztható: karakteradatokra és jelölésre. A jelölést a címkék, a megjegyzések, a feldolgozási utasítások, az egyedhivatkozások, a karakterhivatkozások, a CDATA szakaszhatárolók, az XML-bevezetések, a szövegbevezetések, a dokumentumtípus-bevezetések és a gyökérelem körüli szóközök alkotják. Minden más karakteradat. Példaként itt láthatjuk a DocBook para elemet, ahol a jelöléseket félkövér betűk mutatják, a karakteradatokat pedig sima szöveg jelzi.

<para>

Amennyire ismert, a Fibonacci sorozatokat először Leonardo Pisano

fedezte fel, körülbelül időszámításunk szerint 1200-ban.

Leonardo a <!-- Scritti di Leonardo Pisano. Róma, Baldassarre,

1857. I. kötet, 283-284. oldal Fibonacci,

Leonardo. --> <quote lang="la"><foreignphrase>Quot paria

coniculorum in uno anno ex uno pario germinatur?</foreign

phrase></quote>, kérdést próbálta megválaszolni, ami magyarul

annyit tesz: <quote>Egy év alatt hány pár nyúl születik

egy pártól?</quote> Leonardo problémájának megoldásához először

becslésként mondjuk, hogy a nyulak terhessége egy hónapig tart,

és először egyhónapos korukban képesek párosodni, tehát minden nőstény

kéthónapos korában szüli meg az első almot. Ezután az egyszerűség

kedvéért feltételezzük, hogy minden alomban pontosan egy hím és

egy nőstény születik.

</para>

A következők a jelölések: <para> és a </para> címke, a <quote>, illetve a </quote> címke, a <foreignphrase> és a </foreignphrase> címke, a megjegyzés, valamint az &rsquo egyedhivatkozás. Minden más karakteradat.

A „minden más”-t időnként szövegelemzett karakteradatoknak vagy PCDATA-nak nevezik, mivel a DTD-kben a PCDATA kulcsszó alkalmazásával vezetnek be olyan elemeket, mint az interfacename.

<!ELEMENT interfacename (#PCDATA)>

Ez azonban nem teljesen pontos. Általánosságban a szövegelemzett karakteradat az, ami azután marad, hogy a szövegelemző az egyed- és a karakterhivatkozásokat az általuk jelölt karakterre cseréli. Karakteradatokat és jelölést egyaránt tartalmaz.

Névtér, névtérnév és névtér-URI

Az XML névtér nevek gyűjteménye. Például az XHTML-ben meghatározott elemnevek (html, head, title, body, p, div, table, h1 és a többi) alkotják az XHTML névterét. Az SVG névtér az SVG-ben használt elemek gyűjteménye (svg, rect, polygon, polyline és így tovább). Az előtaggal rendelkező neveknél csupán a helyi rész tartozik a névtérhez. Az előtag és az előtaggal ellátott nevek nem részei a névtérnek.

Minden ilyen névteret egy névtérnév nevű URI hivatkozás azonosít. Az XHTML névtérneve például http://www.w3.org/1999/xhtml. Az SVG névtérneve http://www.w3.org/ 2000/svg. A névtérnév a névteret azonosítja, de nem ő maga a névtér.

A névtérnévnek URI hivatkozásnak kell lennie, de gyakorlatilag nem hiba, ha nem az. Egy névtérnévben például szerepelhetnek olyan karakterek, mint a { vagy a görög l, amelyek az URI-kban nem megengedettek. Ennek ellenére, mivel valójában csaknem az összes névtérnév érvényes URI hivatkozás, a névtérneveket gyakran meggondolatlanul névtér-URI-knak nevezik. Ezek valójában névtér-URI hivatkozások, de a legtöbb fejlesztő nem törődik azzal, hogy ezt kiemelje.

XML dokumentum és XML fájl

Szigorúan véve bármilyen, az XML 1.0 szabványban lefektetett szabályoknak megfelelően elrendezett Unicode karaktersorozat XML dokumentum. Az ilyen dokumentumok lehet, hogy fájlban tárolódnak, de lehet, hogy nem – tárolhatók adatbázis-bejegyzésekben, egy program létrehozhatja azokat a memóriában, kiolvashatók egy hálózati adatfolyamból, könyvbe nyomtathatók, palánkra festhetők, vagy egy metrókocsi ablakába véshetők. Nem feltétlenül van szó fájlokról. Az XML dokumentumok egyetlen fájlban is tárolhatók, vagy külső egyedhivatkozások alkalmazásával több fájl között eloszthatók. Még az is lehetséges, hogy több XML dokumentumot egyetlen fájlban tároljunk, bár ez nem bevett szokás.

Az XML dokumentumok tárgyalásakor időnként hasznos, ha megkülönböztetjük magukat a dokumentumokat a DTD-ktől vagy az egyéb sémafajtáktól. Ezekben az esetekben a sémához illeszkedő tényleges dokumentumot példánydokumentumnak nevezik. Itt a dokumentum egy adott séma példánya.

XML alkalmazás és XML szoftver

Az XML alkalmazás egy séma, leírás vagy valamilyen szabálycsoport által meghatározott XML dokumentumosztály. A Scalable Vector Graphics (SVG), az XHTML, a MathML, a GedML, az XSL Formatting Objects és a DocBooc mind XML alkalmazások. Az az egyszerű nyelv, amelyet a szerző múlt csütörtökön talált ki a képregénygyűjteményének rendezésére, szintén XML alkalmazás, annak ellenére, hogy nem rendelkezik DTD-vel, sémával vagy akár leírással. Az XML alkalmazás nem alkalmazásszoftver, amely valamilyen módon XML-t dolgoz fel, mint az XMLSPY szerkesztő, a Mozilla webböngésző vagy az XEP XSL-FO-PDF átalakító.

Jólformált és érvényes

Az XML dokumentumok két szinten lehetnek „jók”. A jólformáltság (nyelvtani helyesség) a kötelező nyelvtani megkötésekre vonatkozik. Az érvényesség a szabadon választható szerkezeti és jelentésbeli megszorításokra utal. Az érvényes szót gyakran használják a köznyelvi jelentésében, bármilyen helyes dokumentum körülírására. Az XML-ben azonban sokkal pontosabban meghatározott jelentéssel bír. A dokumentumok lehetnek helyesek és végrehajthatók, úgy, hogy mégsem érvényesek.

A jólformáltság alapvető elvárás az XML dokumentumokkal szemben. Különböző nyelvtani megszorításokat foglal magában, például minden nyitó címkéhez záró címkének kell tartoznia, és a dokumentum pontosan egy gyökérelemmel kell, hogy rendelkezzen. Ha egy dokumentum nem jólformált (nyelvtanilag nem helyes), akkor nem XML dokumentum. Az olyan szövegelemzőknek, amelyek helytelen dokumentummal találkoznak, jelezniük kell a hibát, és meg kell szakítaniuk az elemzést. Nem próbálhatják meg kitalálni a dokumentum szerzőjének szándékát. Nem javíthatják ki a hibát és folytathatják, hanem a földre kell söpörniük az egész dokumentumot.

Az érvényesség a jólformáltság egy szigorúbb megkötése, de az XML dokumentumok végrehajtásához nem feltétel. Az érvényesség azt határozza meg, hogy milyen elemek és jellemzők hol jelenhetnek meg. Azt jelzi, hogy a dokumentum követi-e a dokumentumtípus-meghatározásban (DTD) és a dokumentumtípus-bevezetésben (dokumentumtípus-deklaráció, DOCTYPE) felsorolt megkötéseket. Ha a dokumentum nem is felel meg ezeknek a megszorításoknak, bizonyos esetekben ennek ellenére hatékonyan feldolgozható. Az ügyfélprogram dönti el, hogy elutasítja-e az érvénytelen dokumentumokat, és ha igen, milyen módon – nem pedig a szövegelemző.

Az érvényes szót időnként a séma, és nem a DTD érvényességére vonatkozóan használják. Olyankor, amikor ez valószínűleg zavart okoz – különösen amikor az ember várhatóan egy DTD-ben és valamilyen más sémában akarja érvényesíteni a dokumentumot –, a sémaérvényesség szót használják. Ahogy a DTD-érvényesség esetében, itt is az ügyfélprogram dönti el, hogy kezeli-e és hogy miként kezeli a sémaérvénytelen dokumentumot. A sémaérvényesítő szövegelemző értesíti az ügyfélprogramot a dokumentum érvénytelenségéről, de folytatja az elemzést. Az ügyfél dönti el, hogy elfogadja-e a dokumentumot vagy sem.

DTD és DOCTYPE

A dokumentumtípus-meghatározás ELEMENT, ATTLIST, ENTITY és NOTATION bevezetések gyűjteménye, amely egy érvényes dokumentumokból álló osztályt ír le. A dokumentumtípus-bevezetés az XML dokumentumok elején található, és a dokumentum dokumentumtípus-meghatározását tartalmazza, vagy arra mutat. A dokumentumtípus-meghatározás és a dokumentumtípus-bevezetés szorosan összefügg, de nem ugyanaz a kettő. A DTD betűszó kizárólag a dokumentumtípus-meghatározást jelöli, és soha nem a dokumentumtípus-bevezetést. A DOCTYPE rövidítés kizárólag a dokumentumtípus-bevezetésre utal, és soha nem a dokumentumtípus-meghatározásra.

Ez például egy dokumentumtípus-bevezetés:

<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"

"docbook/docbookx.dtd" >

A docbook/docbookx.dtd relatív URL-n található //OASIS/DTD DocBook XML V41.2//EN nyilvános azonosítóval a DTD-re mutat.

Az alábbi szintén dokumentumtípus-bevezetés:

<!DOCTYPE book SYSTEM "http://www.example.com/docbookx.dtd">

A http://example.com/docbookx.dtd abszolút URL-en található DTD-re mutat.

Íme egy dokumentumtípus-bevezetés, amely a DTD-részhalmazt határoló szögletes zárójelek között a teljes DTD-t tartalmazza:

<!DOCTYPE book [

<!ELEMENT book (title, chapter+)>

<!ELEMENT chapter (title, paragraph+)>

<!ELEMENT title (#PCDATA)>

<!ELEMENT paragraph (#PCDATA)>

]>

Végül, a következő dokumentumtípus-bevezetés egy külső DTD-re mutat, és egyúttal egy belső DTD-részhalmazt tartalmaz. A teljes DTD a külső DTD-részhalmazban és a belső DTD-részhalmazban szereplő bevezetések egyesítésével jön létre.

<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"

"docbook/docbookx.dtd" [

<!— add XIncludes —>

<!ENTITY % local.para.char.mix " | xinclude:include">

<!ELEMENT xinclude:include EMPTY>

<!ATTLIST xinclude:include

xmlns:xinclude CDATA #FIXED "http://www.w3.org/2001/XInclude"

href CDATA #REQUIRED

parse (text | xml) "xml"

>

]>

Mindegy, hogy a DTD belső, külső vagy mindkettő, soha nem ugyanaz, mind a dokumentumtípus-bevezetés. A dokumentumtípus-bevezetés a gyökérelemet határozza meg, ellentétben a DTD-vel. A DTD az elemek tartalommodelljét és jellemzőlistáját határozza meg, ellentétben a dokumentumtípus-bevezetéssel. A legtöbb API szokás szerint megjeleníti a dokumentumtípus-bevezetés tartalmát, a dokumentumtípus-meghatározásét azonban nem.

XML-bevezetés és feldolgozási utasítás

Az XML szabvány egyik szükségtelenül zavart okozó jellemzője, hogy a legtöbb XML dokumentum elején megjelenő alábbi szerkezet különböző technikai okok miatt valójában nem feldolgozási utasítás:

<?xml version="1.0"?>

Úgy néz ki, mint egy feldolgozási utasítás, de nem az; ez egy XML-bevezetés. A feldolgozási utasítások célpontjai esetében kifejezetten tilos az xml, XML, Xml vagy az XML szó bármilyen más kis- és nagybetűs változata.

Az API-k lehet, hogy felfedik az XML-bevezetésben szereplő információt az ügyfélnek, és lehet, hogy nem, de amelyik felfedi, nem ugyanazt az eljárást használja, mint amelyet a feldolgozási utasítások jelzésekor alkalmaz. A SAX 2.1-ben például ez az információ igény szerint elérhető a Locator2 felületen keresztül. A szövegelemző azonban nem hívja meg a processingInstruction (feldolgozásiUtasítás) eljárást a contentHandler-ben (tartalomKezelő), amikor meglátja az XML-bevezetést.

Karakterkészlet és karakterkódolás

Az XML a Unicode karakterkészletre épül. A karakterkészlet meghatározott számokhoz, úgynevezett kódpontokhoz rendelt karakterek gyűjteménye. A Unicode 4.0 jelenleg több, mint 90 000 önálló karaktert határoz meg. A készlet minden egyes karakterét egy szám jelöli, például a 64 812 vagy a 87 000. Ezek a számok nem tartoznak az int, a short, a byte, a long vagy bármilyen más számszerű adattípushoz, egyszerűen csak számok. Más karakterkészletek, például a Shift-JIS, illetve a Latin-1 eltérő karaktergyűjteményeket tartalmaznak, amelyek más számokhoz vannak rendelve, bár gyakran jelentős átfedés figyelhető meg a Unicode karakterkészlettel. Ez azt jelenti, hogy számos karakterkészlet bizonyos számú (vagy az összes) karaktert ugyanazokhoz a számokhoz rendeli, amelyekhez a Unicode.

A karakterkódolás egyedi módon ábrázolja a karakterkészletek tagjait. A Unicode-nak többféle kódolása létezik: UTF-8, UTF-16, UCS-2, UCS-4, UTF-32 és még néhány, amelyek kevésbé egyértelműek. A különböző kódolások különböző bájtsorozatok, illetve különböző bájtszám alkalmazásával kódolhatják ugyanazt a kódpontot. Használhatnak nagy vagy kicsi helyiértékre végződő adatokat, sőt nem kettes komplemens ábrázolásmódot is alkalmazhatnak. Kettő vagy négy bájtot használhatnak az egyes karaktereknél, és a különböző karaktereknél akár különböző számú bájtot is alkalmazhatnak.

A karakterkészlet megváltoztatása azt befolyásolja, hogy mely karakterek ábrázolhatók. Az ISO-8859-7 készletben például szerepelnek a görög betűk, míg az ISO-8859-1 készletben nem. A karakterkódolás megváltoztatása nem befolyásolja, hogy mely karakterek használhatók: egyszerűen a karakterek bájtonkénti kódolásának módja változik.

Az XML szövegelemzők mindig más Unicode készletté alakítják a karaktereket az ügyfélprogramnak történő átadásuk előtt. Ennek hatására a többi karakterkészletet a Unicode egy részhalmazának különböző kódolásaiként kezelik. Emiatt az XML nem igazán engedi, hogy megváltoztassuk a karakterkészletet, ami mindig Unicode. Az XML-ben csak a karakterek ábrázolásmódját állíthatjuk be.

URI, URI hivatkozás és IRI

Az URI valamilyen forrást azonosít. Az URI hivatkozás a forrás egy részét jelöli. Az URI hivatkozásban szerepelhet töredékazonosító, amelyet kettős kereszt (#) választ el az URI-tól. Az egyszerű URI-ban nincs ilyen. A http://www.w3.org/TR/REC-xml-names/ például URI, a http://www.w3.org/TR/REC-xml-names/#Philosophy URI hivatkozás.

A legtöbb XML-lel kapcsolatos szabványleírás, például Az XML névterei (Namespaces in XML) inkább URI hivatkozásokkal meghatározott, és nem URI-kkal. A W3C XML sémanyelv egyszerű xsd:anyURI típusa valójában azt határozza meg, hogy az ilyen típusú elemek URI hivatkozások. A köznapi beszédben és írásban a legtöbben nem foglalkoznak ezek megkülönböztetésével, noha fontos lehet. A dokumentumtípus-bevezetésben szereplő rendszerazonosító például csak URI lehet, URI hivatkozás nem.

Vannak, akik azt állítják, hogy a relatív URI-k nem valódi URI-k, hanem URI hivatkozások, és úgy tűnik, az XML szabvány szerzői is ezt a nézetet vallják. Az RFC 2396 URI szabvány azonban nem támogatja ezt az elvet. Világosan leírja a relatív URI-kat és a relatív URI hivatkozásokat is. Lehet, hogy a szerzők szándéka szerint az URI-knak abszolútnak kell lenniük, ha azonban erről van szó, ez nem sikerült. Az URI és az URI hivatkozás között az egyetlen különbség, hogy az utóbbiban engedélyezett a töredékazonosító, míg az előbbiben nem.

Az IETF (Internet Engineering Task Force) jelenleg az Internationalized Resource Identifiers (IRI – nemzetközi erőforrás-azonosító) megalkotásán dolgozik. Ezek az URI-khoz hasonlók, azzal a különbséggel, hogy engedélyezik a nem ASCII karakterek, például a z és az é használatát is, amelyeket az URI-kban a százalékjel használatával kell kikerülni. A szabvány még nincs kész, de számos XML leírás már hivatkozik rá. Az XLink href jellemzője például valójában IRI-t tartalmaz URI helyett.

Séma és a W3C XML sémanyelv

A séma szó az olyan dokumentumok általános kifejezése, amelyek meghatározzák egy dokumentumosztály elrendezését és megengedhető tartalmát. Valójában az adatbázissémával együtt került az informatika fogalmai közé. Az XML-nél több különböző sémanyelv létezik a maguk előnyeivel és hátrányaival – ilyen a DTD, a RELAX NG, a Schematron és természetesen a W3C XML sémanyelv.

A fejlesztők hajlamosak arra, hogy a W3C XML sémanyelvre utalva csak a séma szót, illetve talán a valamivel kevésbé általános XML séma kifejezést használják. Ez kerülendő, mivel a W3C XML sémanyelv nem az egyetlen ilyen nyelv és – a legtöbb ember véleménye szerint – nem is a legegyszerűbb, leghatékonyabb vagy legjobban tervezett. Egyszerűen egy nyelv a sok közül, amelyet egy bizonyos feltalálócsoport népszerűsít. Vannak erősségei és gyengeségei, de nem szabad minden fenntartás nélkül figyelmen kívül hagyni a többi nyelvet (amelyek némelyike igazolhatóan egyszerűbb, illetve hatékonyabb, mint a W3C XML sémanyelv) azzal, hogy általános kifejezéssel utalunk egy konkrét dologra.

Sajnos a W3C nem olyan nevet választott a sémanyelvének, ami egyszerűbb, mint a „W3C XML sémanyelv”, ezért a szerző, hogy ne kelljen vég nélkül ismételgetnie ezt a kifejezést, időnként enged a kísértésnek, és a sémák szót használja a W3C XML sémanyelvre utalva. Ez azonban csak azoknál a pontoknál fordul majd elő, amelyek kizárólag ezt a nyelvet tárgyalják, és az adott fejezet elején ez mindig világosan megjelenik majd. Gondoljunk a séma szóra úgy, mint az éppen tárgyalt sémanyelv névmására, és ne úgy, mint a W3C elterjedésének szimbólumára.

A szavak jelentéssel bírnak. Az XML nagyon pontosan meghatározott nyelv, ezért a szavai is nagyon jól körülírt jelentéssel rendelkeznek. Megéri helyesen használni ezeket a szavakat. Az XML egy-két területe valóban zavaros. Nincs értelme rontani a helyzeten azzal, hogy tovább bonyolítjuk. Ha a megfelelő fogalmakhoz a megfelelő szavakat használjuk, sok indokolatlanul összetett problémát tehetünk egyszerűbbé, és így az agyunk erőforrásait a valóban nehéz helyzetekre tartalékolhatjuk.

A könyv tartalomjegyzéke

Vissza a lap tetejére | A könyv ismertetése

Eliotte Rusty Harold:
Hatékony XML

Tartalomjegyzék

 

Tartalomjegyzék v

A Hatékony XML-ről írták ix

Előszó xi

Köszönetnyilvánítás xv

Bevezetés xvii

1. fejezet Nyelvtan

1. szabály Adjunk meg XML-bevezetést! 1

A version jellemző 2

Az encoding jellemző 3

A standalone jellemző 3

2. szabály ‑A jelöléshez lehetőség szerint használjunk ASCII karakterkészletet! 5

3. szabály Maradjunk az XML 1.0-nál! 9

Új karakterek az XML-nevekben 10

C0 vezérlőkarakterek 12

C1 vezérlőkarakterek 14

A NEL sortörésként használva 14

Unicode-normalizálás 16

Névtérelőtagok visszavonása 16

4. szabály Használjunk szabványos egyedhivatkozásokat! 17

5. szabály Írjunk sok megjegyzést a DTD-be! 19

Fejlécmegjegyzések 21

Bevezetések 23

6. szabály Az elemneveket írjuk púpos írásmóddal! 26

7. szabály Lássuk el paraméterekkel a DTD-ket! 28

Jellemzők paraméterezése 31

Névterek paraméterezése 31

Teljes paraméterezés 33

Feltételes szakaszok 34

8. szabály Tegyük modulárissá a DTD-ket! 36

9. szabály Különböztessük meg a szöveget a jelöléstől! 43

10. szabály A térközök fontosak! 45

Az xml:space jellemző 46

Figyelmen kívül hagyható térköz 46

Címkék és térközök 47

Térközök a jellemzőkben 48

Sémák 49

2. fejezet Szerkezet

11. szabály Jelöléssel tegyük egyértelművé a szerkezetet! 51

Minden információegységet lássunk el címkével! 52

Kerüljük a beleértett szerkezeteket! 55

Hol a határ? 58

12. szabály A metaadatokat tároljuk jellemzőkben! 60

13. szabály Ügyeljünk a vegyes tartalomra! 65

14. szabály Engedélyezzük az XML minden nyelvi elemét! 68

15. szabály A szerkezetekre építsünk, ne a nyelvi elemekre! 71

Üreselem-címkék 74

CDATA szakaszok 75

Karakter- és egyedhivatkozások 77

16. szabály ‑Nem elemzett egyedek és jelölések helyett használjunk URL-eket! 79

17. szabály ‑Folyamatfüggő tartalomhoz használjunk feldolgozási utasításokat! 82

Stílusok helye 83

Egymást átfedő címkék 85

Oldalformázás 87

Túlnyúló jelölés 87

Feldolgozási utasítások helytelen használata 88

18. szabály Helyezzünk minden információt a példánydokumentumba! 90

19. szabály ‑A bináris adatokat quoted printable, illetve Base64 algoritmussal kódoljuk! 94

Quoted printable 94

Base64 96

20. szabály ‑A modularitás és a bővíthetőség érdekében használjunk névtereket! 97

A névtér URI kiválasztása 98

Az érvényesítés és a névterek 101

21. szabály Ne az előtagokra, hanem a névtér URI-kre hagyatkozzunk! 101

22. szabály ‑Ne használjunk névtérelőtagokat az elemtartalomban és a jellemzőértékekben! 105

23. szabály Az általános leíró tartalomhoz hasznosítsuk újra az XHTML-t! 106

24. szabály A megfelelő sémanyelvet válasszuk a feladathoz! 112

A W3C XML sémanyelv 112

Dokumentumtípus-meghatározások 113

RELAX NG 115

Schematron 116

Java, C#, Python és Perl 117

Sémák rétegzése 119

25. szabály Tegyünk úgy, mintha nem létezne a PSVI! 120

26. szabály Jelezzük a dokumentumok, sémák és stíluslapok változatát! 123

27. szabály Jelöljünk jelentés szerint! 128

3. fejezet Jelentés

28. szabály Csak az éppen szükséges eszközöket használjuk! 133

29. szabály Mindig használjunk elemzőprogramot! 139

30. szabály Helyezzük rétegekbe a szolgáltatásokat! 142

31. szabály Programozzunk szabványos programozási felületekkel! 146

SAX 147

DOM 150

JDOM 153

32. szabály A hatékony működéshez válasszuk a SAX-ot! 153

33. szabály A szabványok támogatásához válasszuk a DOM-ot! 158

34. szabály Olvassuk be a teljes DTD-t! 160

35. szabály Mozogjunk a dokumentumban az XPath segítségével! 165

36. szabály Sorosítsuk az XML-t XML-lel! 173

37. szabály Érvényesítsünk a programon belül sémákkal! 174

Xerces-J 177

DOM Level 3 érvényesítés 179

4. fejezet Megvalósítás

38. szabály Használjunk Unicode kódolást! 183

A karakterkódolás kiválasztása 184

A char nem karakter! 187

Normálformák 188

Rendezés 189

39. szabály Lássuk el paraméterekkel az XSLT stíluslapokat! 190

40. szabály Ne kössük magunkat egyetlen gyártóhoz! 194

41. szabály Ragaszkodjunk relációs adatbázisunkhoz! 197

42. szabály A névtereket írjuk le RDDL-lel! 200

A források természete 203

Célok 205

43. szabály Végezzünk kiszolgálóoldali XSLT-előfeldolgozást! 207

Servlet alapú megoldások 208

Apache 209

IIS 210

44. szabály Adjunk át XML-t és CSS-t az ügyfélnek! 211

45. szabály Válasszuk a megfelelő MIME típust! 214

46. szabály Tegyük rendbe a HTML-t! 217

MIME típus 218

HTML Tidy 219

Régebbi böngészők 219

47. szabály Foglaljuk katalógusba a szokványos forrásokat! 221

A katalógusok nyelvtana 222

Katalógusfájlok használata 223

48. szabály Ellenőrizzük a dokumentumokat XML digitális aláírás alapján! 226

A digitális aláírás nyelvtana 227

Eszközök digitális aláíráshoz 234

49. szabály A bizalmas adatokat rejtsük el XML-titkosítással! 236

A titkosítás nyelvtana 237

Titkosító eszközök 241

50. szabály Tömörítsünk, ha a szabad terület korlátozott! 242

Ajánlott olvasmányok 245

 

Tárgymutató 247

Vissza a lap tetejére

mesekönyv

szoftver