XML ehdottomalle aloittelijalle

HTML ja World Wide Web ovat kaikkialla. Esimerkkinä heidän läsnäolostaan menen tänä vuonna Keski-Amerikkaan pääsiäisenä, ja jos haluan, voin surffata verkossa, lukea sähköpostini ja jopa tehdä verkkopankkia Internet-kahviloissa Antigua Guatemala ja Belize City. (En kuitenkaan aio, koska se vie aikaa pois päivältä, jolla minulla on palmu ja rommilla täytetty kookos.)

Ja silti, huolimatta HTML: n läsnäolosta ja suosiosta, siinä on voimakkaasti rajoitettu mitä se voi tehdä. Se on hieno epävirallisten asiakirjojen levittämisestä, mutta HTML: ää käytetään nyt tekemään asioita, joita ei ole koskaan suunniteltu. Yritän suunnitella raskaita, joustavia ja yhteentoimivia tietojärjestelmiä HTML: stä on kuin yrittää rakentaa lentotukialusta rautasahoilla ja juoteilla: työkalut (HTML ja HTTP) eivät vain ole työssä.

Hyvä uutinen on, että monet HTML: n rajoituksista on ylitetty XML: ssä, Extensible Markup Language. XML on helposti ymmärrettävä kaikille, jotka ymmärtävät HTML: n, mutta se on paljon tehokkaampi. XML on muutakin kuin vain merkintäkieli metakieli - kieli, jolla määritetään uudet merkintäkielet. XML: n avulla voit luoda nimenomaan sovelluksellesi tai verkkotunnuksellesi suunnitellun kielen.

XML täydentää HTML: ää pikemminkin kuin korvaa sen. HTML: ää käytetään tietojen muotoiluun ja näyttämiseen, mutta XML edustaa tietojen asiayhteyteen liittyvää merkitystä.

Tässä artikkelissa esitellään merkintäkielien historia ja XML: n synty. Tarkastelemme HTML-näytetietoja ja siirrymme vähitellen XML-muotoon osoittaen, miksi se tarjoaa erinomaisen tavan edustaa tietoja. Tutkimme syitä, jotka saatat joutua keksimään mukautetun merkintäkielen, ja opetan sinulle, miten se tehdään. Käsittelemme XML-merkintöjen perusteet ja kuinka XML voidaan näyttää kahdella erilaisella tyylikielellä. Sitten sukellamme Document Object Model -ohjelmaan, joka on tehokas työkalu asiakirjojen manipuloimiseksi esineinä (tai objektirakenteiden manipuloimiseksi asiakirjoina sen mukaan, miten katsot sitä). Käymme läpi kuinka kirjoittaa Java-ohjelmia, jotka poimivat tietoja XML-asiakirjoista, osoittimella ilmaiseen ohjelmaan, joka on hyödyllinen kokeilemaan näitä uusia käsitteitä. Lopuksi katsomme Internet-yritystä, joka perustaa ydinteknologian strategiansa XML: ään ja Java: iin.

Onko XML sinulle?

Vaikka tämä artikkeli on kirjoitettu kaikille, jotka ovat kiinnostuneita XML: stä, sillä on erityinen suhde XML: ään JavaWorld XML JavaBeans -sarja. (Katso linkit aiheeseen liittyviin artikkeleihin Resursseista.) Jos olet lukenut kyseistä sarjaa etkä aivan ymmärrä sitä, tämän artikkelin tulisi selventää XML: n käyttöä papujen kanssa. Jos sinä ovat Tämän saamiseksi tämä artikkeli toimii täydellisenä kumppanina XML JavaBeans -sarjassa, koska se kattaa siinä koskemattomat aiheet. Ja jos olet yksi harvoista onnekkaista, joilla on vielä odotettavissa olevia XML JavaBeans -artikkeleita, suosittelen, että luet tämän artikkelin ensin johdantomateriaalina.

Huomautus Javasta

Tietokonemaailmassa on niin paljon viimeaikaista XML-toimintaa, että jopa tämän pituinen artikkeli voi vain ohittaa pinnan. Tämän artikkelin tarkoituksena on silti antaa asiayhteys, jota sinun on käytettävä XML: ää Java-ohjelmissasi. Tässä artikkelissa käsitellään myös XML: n toimintaa nykyisen verkkotekniikan kanssa, koska monet Java-ohjelmoijat työskentelevät tällaisessa ympäristössä.

XML avaa Internetin ja Java-ohjelmoinnin kannettaville, selaimen ulkopuolisille toiminnoille. XML vapauttaa Internet-sisällön selaimesta samalla tavalla kuin Java vapauttaa ohjelmakäyttäytymisen alustalta. XML tekee Internet-sisällön saataville todellisille sovelluksille.

Java on erinomainen alusta XML: n käyttöön, ja XML on erinomainen dataesitys Java-sovelluksille. Esitän joitain Java-vahvuuksia XML: n kanssa, kun jatkamme.

Aloitetaan historian oppitunnilla.

Merkintäkielien alkuperä

HTML, jonka me kaikki tiedämme ja jota rakastamme (hyvin, että tiedämme joka tapauksessa), on alun perin suunnitellut Tim Berners-Lee CERN: ssä (le Conseil Européen pour la Recherche Nucléaire, tai Euroopan hiukkasten fysiikan laboratorio) Genevessä, jotta fysiikan nörtit (ja jopa muut nörtit) voivat kommunikoida keskenään. HTML julkaistiin joulukuussa 1990 CERN: ssä, ja se tuli yleisesti saataville kesällä 1991 muille meille. CERN ja Berners-Lee luovuttivat HTML-, HTTP- ja URL-osoitteiden eritelmät vanhassa hienossa Internet-jakamisen ja nauttimisen perinteessä.

Berners-Lee määritteli HTML: n SGML: ssä, joka on yleinen yleinen merkintäkieli. SGML, kuten XML, on metakieli - kieli, jota käytetään määrittelemään muita kieliä. Kutakin niin määriteltyä kieltä kutsutaan sovellus SGML. HTML on SGML-sovellus.

SGML syntyi tutkimuksesta, joka tehtiin pääasiassa IBM: llä tekstidokumenttien esittämisestä 60-luvun lopulla. IBM loi GML: n ("General Markup Language"), SGML: n edeltäjän, ja vuonna 1978 American National Standards Institute (ANSI) loi ensimmäisen versionsa SGML: stä. Ensimmäinen standardi julkaistiin vuonna 1983, standardiluonnos julkaistiin vuonna 1985, ja ensimmäinen standardi julkaistiin vuonna 1986. Kiinnostavaa kyllä, ensimmäinen SGML-standardi julkaistiin käyttämällä Anders Berglundin CERNissä kehittämää SGML-järjestelmää, organisaatiota, joka olemme nähneet, antaneet meille HTML: n ja Webin.

SGML: ää käytetään laajalti suurilla teollisuudenaloilla ja hallituksissa, kuten suurissa ilmailu-, auto- ja teleyrityksissä. SGML: ää käytetään dokumenttistandardina Yhdysvaltain puolustusministeriössä ja Internal Revenue Service -palvelussa. (Yhdysvaltojen ulkopuolella oleville lukijoille IRS on veropoika.)

Albert Einstein sanoi, että kaikesta tulisi tehdä mahdollisimman yksinkertaista eikä yksinkertaisempaa. SGML: ää ei löydy useammasta paikasta, koska se on erittäin hienostunut ja monimutkainen. Ja HTML, jonka löydät kaikkialta, on hyvin yksinkertainen; monille sovelluksille se on liian yksinkertaista.

HTML: Kaikki muodot, ei sisältöä

HTML on kieli, joka on suunniteltu "puhumaan" asiakirjoista: otsikot, otsikot, kuvatekstit, fontit ja niin edelleen. Se on voimakkaasti asiakirjojen rakenne- ja esityskeskeinen.

Tosin taiteilijat ja hakkerit ovat pystyneet tekemään ihmeitä suhteellisen tylsällä HTML-työkalulla. Mutta HTML: llä on vakavia haittoja, jotka tekevät siitä huonosti sopivan joustavien, tehokkaiden, evoluutiojärjestelmien suunnitteluun. Tässä muutama tärkeimmistä valituksista:

HTML-koodia ei voi laajentaa
Laajennettava merkintäkieli antaisi sovelluskehittäjille mahdollisuuden määrittää mukautettuja tunnisteita sovelluskohtaisiin tilanteisiin. Ellet ole 600 kilon gorilla (ja ehkä ei silloinkin), et voi vaatia kaikkia selaimen valmistajia toteuttamaan kaikki sovelluksellesi tarvittavat merkintätagit. Joten olet jumissa sen kanssa, mitä suuret selainvalmistajat tai W3C (World Wide Web Consortium) antavat sinulle. Tarvitsemme kielen, jonka avulla voimme muodostaa omat merkintätagit ilman, että meidän tarvitsee soittaa selaimen valmistajalle.
HTML on hyvin näyttökeskeinen
HTML on hieno kieli näyttötarkoituksia varten, ellet vaadi paljon tarkkaa muotoilua tai muunnoksen hallintaa (jolloin se haisee). HTML edustaa sekoitusta asiakirjan loogisesta rakenteesta (otsikot, kappaleet ja vastaavat) esitystageista (lihavoitu, kuvan tasaus jne.). Koska melkein kaikki HTML-tunnisteet liittyvät siihen, miten tietoja näytetään selaimessa, HTML on hyödytön muille tavallisille verkkosovelluksille - kuten tietojen replikoinnille tai sovelluspalveluille. Tarvitsemme tavan yhtenäistää nämä yleiset toiminnot näytöllä, joten sama palvelin, jota käytetään tietojen selaamiseen, voi myös suorittaa esimerkiksi yritystoimintoja ja toimia yhdessä vanhojen järjestelmien kanssa.
HTML ei yleensä ole suoraan uudelleenkäytettävissä
Asiakirjojen luominen tekstinkäsittelyohjelmissa ja sitten vieminen HTML-muodossa on jonkin verran automatisoitua, mutta vaatii kuitenkin ainakin jonkin verran tuotoksen säätämistä hyväksyttävien tulosten saavuttamiseksi. Jos tiedot, joista asiakirja on tuotettu, muuttuvat, koko HTML-käännös on tehtävä uudestaan. Sivustot, jotka näyttävät tämänhetkisen sään ympäri maailmaa ympäri vuorokauden, käsittelevät yleensä tämän automaattisen muotoilun erittäin hyvin. Asiakirjan sisältö ja esitystyyli erotetaan toisistaan, koska järjestelmän suunnittelijat ymmärtävät, että heidän sisällönsä (lämpötilat, ennusteet jne.) Muuttuvat jatkuvasti. Tarvitsemme tavan määrittää tietojen esitys rakenteen suhteen, jotta tietoja päivitettäessä muotoilua voidaan "soveltaa uudelleen" johdonmukaisesti ja helposti.
HTML tarjoaa vain yhden näkymän tiedoista
On vaikea kirjoittaa HTML-koodia, joka näyttää samat tiedot eri tavoin käyttäjien pyyntöjen perusteella. Dynaaminen HTML on alku, mutta se vaatii valtavan määrän komentosarjoja, eikä se ole yleinen ratkaisu tähän ongelmaan. (Dynaamista HTML-koodia käsitellään tarkemmin jäljempänä.) Tarvitsemme tavan saada kaikki tiedot, joita voimme haluta selata kerralla, ja tarkastella niitä eri tavoin asiakkaalla.
HTML: llä on vähän tai ei ollenkaan semanttista rakennetta
Useimmat verkkosovellukset hyötyisivät kyvystä edustaa tietoja merkityksen eikä asettelun mukaan. Esimerkiksi Internetissä voi olla hyvin vaikeaa löytää etsimäsi, koska HTML-tiedostoissa olevien tietojen merkityksestä ei ole tietoa (lukuun ottamatta META-tunnisteita, jotka ovat yleensä harhaanjohtavia). Tyyppi
punainen
hakukoneeseen, ja saat linkkejä Red Skeltoniin, punaiseen silliin, punaiseen snapperiin, punaiseen peloon, Red Letter Day -ohjelmaan ja luultavasti sivulle tai kahdelle "Books I'm Red" -sivulta. HTML: llä ei ole tapaa määrittää, mitä tietty sivun kohde tarkoittaa. Hyödyllisempi merkintäkieli edustaisi tietoa sen merkityksen kannalta. Tarvitsemme kielen, joka ei kerro meille miten
näyttö
vaan pikemminkin mikä tietyn tietolohkon
On
joten tiedämme mitä tehdä sen kanssa.

SGML: llä ei ole mitään näistä heikkouksista, mutta jotta se olisi yleinen, se on hiuksia repäisevä monimutkainen (ainakin täydellisessä muodossaan). SGML: n (sen "tyylikieli") muotoilussa käytetty kieli, nimeltään DSSSL (Document Style Semantics and Specification Language), on erittäin tehokas, mutta sitä on vaikea käyttää. Kuinka saamme kielen, joka on suunnilleen yhtä helppokäyttöinen kuin HTML, mutta jolla on suurin osa SGML: n voimasta?

XML: n alkuperä

Kun verkko räjähti ja ihmiset ympäri maailmaa alkoivat oppia HTML: stä, he alkoivat melko nopeasti törmätä yllä esitettyihin rajoituksiin. Raskasmetalliset SGML-vinssit, jotka olivat työskennelleet SGML: n kanssa vuosia suhteellisen hämärässä, huomasivat yhtäkkiä, että jokapäiväiset ihmiset ymmärsivät jonkin verran merkintöjen (ts. HTML) käsitettä. SGML-asiantuntijat alkoivat miettiä mahdollisuutta käyttää SGML: ää suoraan verkossa sen sijaan, että käyttäisivät vain yhtä sen sovellusta (taas HTML). Samalla he tiesivät, että vaikka SGML oli tehokas, se oli yksinkertaisesti liian monimutkainen useimpien ihmisten käytettäväksi.

Kesällä 1996 Jon Bosak (tällä hetkellä Sun Microsystemsin online-tietotekniikka-arkkitehti) vakuutti W3C: n antamaan hänen muodostaa komitean SGML: n käytöstä verkossa. Hän loi SGML-maailmasta voimakkaan muffety-mukkitiimin. Kyseisen vuoden marraskuuhun mennessä nämä ihmiset olivat luoneet yksinkertaistetun SGML-muodon aloitteen, joka sisälsi SGML: n kokeiltuja ja todellisia ominaisuuksia, mutta monimutkaisuudeltaan. Tämä oli ja on XML.

Maaliskuussa 1997 Bosak julkaisi merkittävän paperinsa "XML, Java ja Webin tulevaisuus" (katso Resurssit). Nyt, kaksi vuotta myöhemmin (hyvin kauan Webin elämässä), Bosakin lyhyt artikkeli on edelleen hyvä, jos päivätty, johdatus siihen, miksi XML: n käyttö on niin erinomainen idea.

SGML luotiin asiakirjojen yleistä jäsentämistä varten, ja HTML luotiin SGML: n sovelluksena Web-asiakirjoihin. XML on SGML: n yksinkertaistaminen yleiseen verkkokäyttöön.

XML-käsitteellinen esimerkki

Kaikki tämä puhe "omien tunnisteidesi keksimisestä" on melko sumuinen: millaisia tunnisteita kehittäjä haluaa keksiä ja miten tuloksena olevaa XML: ää käytetään? Tässä osassa käydään läpi esimerkki, jossa verrataan ja kontrastoidaan HTML-ja XML-tietojen esittämistä. Seuraavassa osiossa ("XSL: Pidän tyylistäsi") käydään läpi XML-näyttö.

Ensin otamme esimerkin reseptistä ja näytämme sen yhtenä mahdollisena HTML-asiakirjana. Sitten teemme esimerkin uudelleen XML: ssä ja keskustelemme siitä, mikä ostaa meitä.

HTML-esimerkki

Katsokaa pientä HTML-osaa luettelossa 1:

Lime Jello Marshmallow -juusto-yllätys

Isoäitini suosikki (lepääkö hän rauhassa).

Ainekset

Määrä	Yksiköt	Tuote
1	laatikko	kalkki gelatiini
500	g	monivärisiä pieniä vaahtokarkkeja
500	ml	raejuusto
	viiva	Tabasco-kastike (valinnainen)

Ohjeet

Valmista kalkin gelatiini pakkauksen ohjeiden mukaisesti ...

Listaus 1. Jotkut HTML

(Tulostettava versio tästä luettelosta löytyy osoitteesta example.html.)

Listan 1 HTML-koodia tarkasteltaessa on luultavasti kenellekään selvää, että tämä on resepti jollekin (jotain kauheaa, mutta resepti silti). HTML-tiedostomme tuottaa selaimessa jotain tällaista:

Lime Jello Marshmallow -juusto-yllätys

Isoäitini suosikki (lepääkö hän rauhassa).

Ainekset

Määrä	Yksiköt	Tuote
1	laatikko	kalkki gelatiini
500	g	monivärisiä pieniä vaahtokarkkeja
500	ml	Raejuusto
	viiva	Tabasco-kastike (valinnainen)

Ohjeet

Valmista kalkin gelatiini pakkauksen ohjeiden mukaisesti ...

Listaus 2. miltä listan 1 HTML-koodi näyttää selaimessa

Tämän reseptin esittämisessä HTML-muodossa on useita etuja seuraavasti:

Se on melko luettavissa. Merkintä voi olla hieman salaperäinen, mutta jos se on asetettu oikein, sitä on melko helppo seurata.
HTML voidaan näyttää lähes kaikilla HTML-selaimilla, jopa ilman graafisia ominaisuuksia. Se on tärkeä asia: Näyttö on selaimesta riippumaton. Jos tämän reseptin tekemisen tuloksista olisi valokuva (ja varmasti toivotaan, ettei niitä ole), se näkyy graafisessa selaimessa, mutta ei tekstiselaimessa.
Voit käyttää CSS-tyylitaulukkoa (CSS - puhumme vähän alla olevista) yleiseen muotoilun hallintaan.

HTML: llä tietomuodona on kuitenkin yksi suuri ongelma. merkitys asiakirjan eri tiedoista menetetään. On todella vaikeaa ottaa yleinen HTML-koodi ja selvittää, mitä HTML-tiedot tarkoittavat. Se, että siellä on tämän reseptin kanssa (määrä) 500 ml () raejuustoa olisi erittäin vaikea purkaa tästä asiakirjasta tavalla, joka on yleensä merkityksellistä.

Nyt ajatus HTML-asiakirjan tiedoista mikä tarkoittaa jotain voi olla vähän vaikea ymmärtää. Verkkosivut ovat hieno ihmislukijalle, mutta jos ohjelma aikoo käsitellä asiakirjaa, se edellyttää yksiselitteisiä määritelmiä tunnisteiden merkityksestä. Esimerkiksi HTML-asiakirjan tunniste liittää asiakirjan otsikon. Tätä tagi tarkoittaa, eikä se tarkoita mitään muuta. Samoin HTML tag tarkoittaa "taulukkorivi", mutta siitä ei ole juurikaan hyötyä, jos ohjelmasi yrittää lukea reseptejä esimerkiksi luodaksesi ostoslistan. Kuinka ohjelma voisi löytää ainesosaluettelon HTML-muodossa muotoillulta verkkosivulta?

Toki, voit kirjoittaa ohjelman, joka tarttuu otsikoihin dokumentista, lukee taulukon sarakeotsikot, selvittää kunkin ainesosan määrät ja yksiköt jne. Ongelmana on, että jokainen muotoilee reseptit eri tavalla. Entä jos yrität saada näitä tietoja esimerkiksi Julia Childsin verkkosivustolta, ja hän jatkuu muotoilun kanssa? Jos Julia muuttaa sarakkeiden järjestystä tai lopettaa taulukoiden käytön, hän rikkoo ohjelmasi! (Vaikka on sanottava: Jos Julia alkaa julkaista tällaisia reseptejä, hän voi haluta miettiä uran vaihtamista.)

Kuvittele nyt, että tämä reseptisivu on peräisin tietokannan tiedoista ja haluat pystyä lähettämään nämä tiedot ympäri. Ehkä haluat lisätä sen kotisi valtavaan reseptitietokantaan, josta voit hakea ja käyttää sitä haluamallasi tavalla. Valitettavasti syötteesi on HTML, joten tarvitset ohjelman, joka osaa lukea tämän HTML-koodin, selvittää kaikki "Ainesosat", "Ohjeet", "Yksiköt" ja niin edelleen ja tuoda ne sitten tietokantaan. Se on paljon työtä. Varsinkin kun kaikki tämä semanttinen tieto - jälleen tietojen merkitys - oli olemassa alkuperäisessä tietokannassa, mutta se oli hämärtynyt muunnettaessa HTML-muotoon.

Kuvittele nyt, että voisit keksiä oman mukautetun kielesi reseptien kuvaamiseen. Sen sijaan, että kuvailisit, miten resepti näytettiin, kuvailisit tietorakenne reseptissä: kuinka kukin tieto koskisi muita kappaleita.

XML-esimerkki

Tehdään vain merkintäkieli reseptien kuvaamiseksi ja kirjoitetaan reseptimme uudestaan kyseisellä kielellä, kuten Listing 3: ssa.

  Lime Jello Marshmallow -juustot yllätys Mummon suosikki (lepääkö hän rauhassa). 1 kalkkigeelatiini 500 monivärinen pieni vaahtokarkki 500 Raejuusto Tabasco-kastike Valmista kalkkigeelatiini pakkauksen ohjeiden mukaan

Listaus 3. Reseptien mukautettu merkintäkieli

Sinulle, koska olet älykäs lukija, tulee olemaan pieni yllätys, että tämä resepti uudessa muodossaan on itse asiassa XML-asiakirja. Ehkä se, että tiedosto alkoi parittomalla otsikolla

antoi sen pois; Itse asiassa jokaisen XML-tiedoston tulisi alkaa tällä otsikolla. Olemme yksinkertaisesti keksineet merkintätunnisteet, joilla on tietty merkitys; esimerkiksi "An on (määrä ilmoitettuina yksikköinä) yhden , mikä on mahdollisesti valinnainen"XML - dokumenttimme kuvaa reseptissä olevat tiedot muodossa reseptit, sen sijaan, miten näyttö resepti (kuten HTML: ssä). Informaation semantiikkaa tai merkitystä ylläpidetään XML: ssä, koska se on suunniteltu tekemään tagit.

Huomautuksia merkinnöistä

On tärkeää saada nimikkeistö suoraksi. Kuvassa 1 näet a aloitustunniste, joka alkaa suljetulla tekstialueella, joka tunnetaan nimellä Tuote, mukaan merkin nimi. Kuten HTML: ssä, XML-tunnisteet voivat sisältää luettelon määritteet (koostuu ominaisuuden nimi ja määritteen arvo.) Tuote tunnisteen määrittämä päättyy lopputunniste.

Kaikki tunnisteet eivät sisällä tekstiä. HTML-muodossa

tag tarkoittaa "rivinvaihto" eikä sisällä tekstiä. XML: ssä tällaiset elementit eivät ole sallittuja. Sen sijaan XML: llä on tyhjät tunnisteet, merkitty kauttaviivalla ennen tagin viimeistä suorakulmaista kiinnikettä. Kuvassa 2 on tyhjä tagi XML-reseptistämme. Huomaa, että tyhjillä tunnisteilla voi olla määritteitä. Tämä tyhjä tagiesimerkki on standardi XML-lyhenne .

Näiden HTML: ään liittyvien notaatioerojen lisäksi XML: n rakennesäännöt ovat tiukemmat. Jokaisen XML-asiakirjan on oltava hyvin muodostunut. Mitä tuo tarkoittaa? Jatka lukemista!

Ooh La La! Hyvin muodostettu XML

Hyvin muotoillun käsite tulee matematiikasta: On mahdollista kirjoittaa matemaattisia lausekkeita, jotka eivät tarkoita mitään.Esimerkiksi lauseke

2 ( + + 5 (=) 9 > 7

näyttää (tavallaan) matematiikalta, mutta se ei ole matematiikkaa, koska se ei noudata matemaattisen lausekkeen notaatio- ja rakennesääntöjä (ainakaan tällä planeetalla). Toisin sanoen yllä oleva "lauseke" ei ole hyvin muodostunut. Matemaattisten lausekkeiden on oltava hyvin muotoiltuja, ennen kuin voit tehdä mitään hyödyllistä heidän kanssaan, koska lausekkeet, jotka eivät ole hyvin muotoiltuja, ovat merkityksettömiä.

Hyvin muotoiltu XML-asiakirja on yksinkertaisesti sellainen, joka noudattaa kaikkia XML: n notaatio- ja rakennesääntöjä. Ohjelmien, jotka aikovat käsitellä XML: ää, tulisi hylätä kaikki XML-syötteet, jotka eivät noudata sääntöjen mukaista muotoilua. Tärkeimmät näistä säännöistä ovat seuraavat:

Ei sulkemattomia tunnisteita
Voit päästä eroon kaikenlaisista wacko-asioista HTML-muodossa. Esimerkiksi useimmissa HTML-selaimissa voit "avata" luettelokohteen

Ei päällekkäisiä tunnisteita
Toisen tunnisteen sisällä avautuvan tunnisteen on sulkeuduttava ennen sisältävän tunnisteen sulkemista. Esimerkiksi järjestys
Katkaistaan koko asia
ei ole hyvin muodostettu, koska avautuu mutta ei sulkeudu sisälle . Oikean järjestyksen on oltava
Katkaistaan koko asia
Toisin sanoen asiakirjan rakenteen on oltava tiukasti hierarkkinen.
Määritearvot on liitettävä lainausmerkkeihin
Toisin kuin HTML, XML ei salli "paljaita" määritearvoja (ts. HTML-tunnisteita, kuten
, jossa määritteen arvon ympärillä ei ole lainausmerkkejä). Jokaisella attribuutin arvolla on oltava lainausmerkit ().
Tekstimerkit () ja (") on aina edustettava merkkikokonaisuuksilla
Jos haluat edustaa näitä kolmea merkkiä (vasen kulmasulku, suorakulmainen sulku ja lainausmerkit) XML: n tekstiosassa (ei merkinnässä), sinun on käytettävä erikoismerkkejä (
<
), (
>
) ja (
"
). Nämä merkit ovat XML: n erikoismerkkejä. XML-tiedosto, joka käyttää sanan kaksoislainausmerkkiä XML-tiedoston tunnisteisiin suljetussa tekstissä, ei ole hyvin muodostettu, ja oikein suunnitellut XML-jäsentimet tuottavat virheen tällaiselle syötteelle.

'Hyvin muodostettu' tarkoittaa 'parsable'

Yleinen XML jäsennin on ohjelma tai luokka, joka voi lukea minkä tahansa hyvin muodostetun XML: n syötteestään. Monet toimittajat tarjoavat nyt XML-jäsentimiä Java-muodossa ilmaiseksi; (Löydät linkit näihin paketteihin tämän artikkelin alaosassa olevista Resursseista). XML-jäsentimet tunnistavat hyvin muotoillut asiakirjat ja tuottavat virheilmoituksia (aivan kuten kääntäjä tekisi), kun he saavat syötteen, joka ei ole oikein muotoiltu. Kuten näemme, tämä toiminto on erittäin kätevä ohjelmoijalle: Soitat yksinkertaisesti valitsemallesi jäsentäjälle ja se huolehtii virheiden havaitsemisesta ja niin edelleen. Vaikka kaikki XML-jäsentäjät tarkistavat asiakirjojen hyvin muotoillun (mikä tarkoittaa, kuten olemme nähneet, että kaikilla tunnisteilla on merkitystä, ne on sijoitettu oikein jne.), vahvistaminen XML-jäsentäjät menevät askeleen pidemmälle. Vahvistavat jäsentimet vahvistavat myös asiakirjan olevan pätevä; eli tagien rakenteella ja lukumäärällä on järkeä.

Esimerkiksi useimmat selaimet näyttävät asiakirjan, jolla on (järjetöntä) kaksi elementtejä, mutta miten se voi olla? Vain yksi otsikko tai ei otsikkoa ole järkevää.

Toisena esimerkkinä kuvittele, että luettelossa 3 "raejuusto" ainesosa näytti tältä:

  500 9 Raejuusto

Tämä XML-asiakirja on varmasti hyvin muotoiltu, mutta sillä ei ole järkeä. Ei se ole rakenteellisesti pätevä. Se on hölynpölyä a sisältää <Määrä>. Mikä on tästä ?

Ongelmana on, että meillä on hyvin muotoiltu asiakirja, mutta se ei ole kovin hyödyllinen, koska XML: llä ei ole järkeä. Tarvitsemme tavan määrittää, mikä tekee XML-dokumentista kelvollisen. Esimerkiksi kuinka voimme määrittää, että a tagi voi sisältää vain tekstiä (eikä muita elementtejä) ja ilmoittaa virheinä muissa tapauksissa?

Vastaus tähän kysymykseen on nimeltään asiakirjatyypin määrittely, jota tarkastelemme seuraavaksi.