XML til den absolutte begynder

HTML og World Wide Web er overalt. Som et eksempel på deres allestedsnærværende skal jeg til Mellemamerika til påske i år, og hvis jeg vil, vil jeg være i stand til at surfe på nettet, læse min e-mail og endda lave internetbank fra internetcaféer i Antigua Guatemala og Belize City. (Jeg har dog ikke til hensigt at tage tid væk fra en dato, jeg har med et palme og en romfyldt kokosnød, da jeg gør det.)

Og på trods af HTMLs allestedsnærværelse og popularitet er den stærkt begrænset i, hvad den kan gøre. Det er fint at sprede uformelle dokumenter, men HTML bruges nu til at gøre ting, det aldrig blev designet til. At forsøge at designe tunge, fleksible, interoperable datasystemer fra HTML er som at prøve at bygge et hangarskib med hacksave og loddejern: værktøjerne (HTML og HTTP) er bare ikke op til opgaven.

Den gode nyhed er, at mange af HTML-begrænsningerne er overvundet i XML, Extensible Markup Language. XML er let forståelig for alle, der forstår HTML, men det er meget mere kraftfuldt. Mere end blot et markup-sprog er XML en metalsprog - et sprog, der bruges til at definere nye markup-sprog. Med XML kan du oprette et sprog, der er designet specielt til din applikation eller dit domæne.

XML supplerer snarere end erstatter HTML. Mens HTML bruges til formatering og visning af data, repræsenterer XML den kontekstuelle betydning af dataene.

Denne artikel vil præsentere historikken for markup-sprog, og hvordan XML blev til. Vi ser på eksempeldata i HTML og flytter gradvist ind i XML, hvilket viser, hvorfor det giver en overlegen måde at repræsentere data på. Vi undersøger grundene til, at du muligvis har brug for at opfinde et brugerdefineret markup-sprog, og jeg lærer dig, hvordan du gør det. Vi dækker det grundlæggende i XML-notation, og hvordan man viser XML med to forskellige slags stilsprog. Derefter dykker vi ned i Document Object Model, et kraftfuldt værktøj til at manipulere dokumenter som objekter (eller manipulere objektstrukturer som dokumenter, afhængigt af hvordan du ser på det). Vi gennemgår, hvordan man skriver Java-programmer, der udtrækker information fra XML-dokumenter, med en markør til et gratis program, der er nyttigt til at eksperimentere med disse nye koncepter. Endelig vil vi se på et internetfirma, der baserer sin kerneteknologistrategi på XML og Java.

Er XML noget for dig?

Selvom denne artikel er skrevet til alle interesserede i XML, har den et særligt forhold til JavaWorld serie på XML JavaBeans. (Se ressourcer for links til relaterede artikler.) Hvis du har læst den serie og ikke helt "får det", bør denne artikel præcisere, hvordan du bruger XML med bønner. hvis du er for at få det, fungerer denne artikel som det perfekte ledsagerstykke til XML JavaBeans-serien, da den dækker emner, der er uberørt deri. Og hvis du er en af de få heldige, der stadig har XML JavaBeans-artiklerne at se frem til, anbefaler jeg, at du først læser denne artikel som indledende materiale.

En note om Java

Der er så meget nyere XML-aktivitet i computerverdenen, at selv en artikel af denne længde kun kan skumme overfladen. Alligevel er hele pointen med denne artikel at give dig den kontekst, du har brug for til at bruge XML i dine Java-programdesign. Denne artikel dækker også, hvordan XML fungerer med eksisterende webteknologi, da mange Java-programmører arbejder i et sådant miljø.

XML åbner internet- og Java-programmering for bærbar funktion, der ikke er browser. XML frigør internetindhold fra browseren på samme måde som Java frigør programadfærd fra platformen. XML gør internetindhold tilgængeligt for rigtige applikationer.

Java er en fremragende platform til brug af XML, og XML er en fremragende datarepræsentation for Java-applikationer. Jeg vil påpege nogle af Java's styrker med XML, når vi går videre.

Lad os begynde med en historieundervisning.

Oprindelsen til markup-sprog

HTML'en, som vi alle kender og elsker (ja, det ved vi alligevel) blev oprindeligt designet af Tim Berners-Lee hos CERN (le Conseil Européen pour la Recherche Nucléaire, eller Det Europæiske Laboratorium for Partikelfysik) i Genève for at give fysiske nørder (og endda ikke-nørder) mulighed for at kommunikere med hinanden. HTML blev udgivet i december 1990 inden for CERN og blev offentligt tilgængelig i sommeren 1991 for resten af os. CERN og Berners-Lee gav væk specifikationerne for HTML, HTTP og URL'er i den fine gamle tradition for internet-del og nyd.

Berners-Lee definerede HTML i SGML, Standard Generalized Markup Language. SGML er, ligesom XML, en metalsprog - et sprog, der bruges til at definere andre sprog. Hvert så defineret sprog kaldes en Ansøgning af SGML. HTML er en applikation af SGML.

SGML kom frem fra forskning, der primært blev foretaget hos IBM om tekstdokumentrepræsentation i slutningen af 60'erne. IBM oprettede GML ("General Markup Language"), et forgængersprog til SGML, og i 1978 oprettede American National Standards Institute (ANSI) sin første version af SGML. Den første standard blev udgivet i 1983, med udkastet til standard udgivet i 1985, og den første standard blev offentliggjort i 1986. Interessant nok blev den første SGML-standard udgivet ved hjælp af et SGML-system udviklet af Anders Berglund hos CERN, den organisation, der som vi har set, gav os HTML og internettet.

SGML bruges i vid udstrækning i store industrier og regeringer som i store luftfarts-, bil- og telekommunikationsvirksomheder. SGML bruges som dokumentstandard i USAs forsvarsministerium og Internal Revenue Service. (For læsere uden for USA er IRS skattemændene.)

Albert Einstein sagde, at alt skulle gøres så simpelt som muligt og ikke enklere. Årsagen til, at SGML ikke findes flere steder, er, at den er ekstremt sofistikeret og kompleks. Og HTML, som du kan finde overalt, er meget enkel; til mange applikationer er det for simpelt.

HTML: Al form og intet stof

HTML er et sprog designet til at "tale om" dokumenter: overskrifter, titler, billedtekster, skrifttyper og så videre. Det er stærkt dokumentstruktur- og præsentationsorienteret.

Ganske vist har kunstnere og hackere været i stand til at udføre mirakler med det relativt kedelige værktøj kaldet HTML. Men HTML har alvorlige ulemper, der gør det dårligt egnet til at designe fleksible, kraftfulde, evolutionære informationssystemer. Her et par af de største klager:

HTML kan ikke udvides
Et udvideligt markup-sprog giver applikationsudviklere mulighed for at definere brugerdefinerede tags til applikationsspecifikke situationer. Medmindre du er en 600 pund gorilla (og måske ikke engang dengang), kan du ikke kræve, at alle browserproducenter implementerer alle de markeringskoder, der er nødvendige for din applikation. Så du sidder fast med, hvad de store browserproducenter eller W3C (World Wide Web Consortium) vil lade dig have. Hvad vi har brug for er et sprog, der giver os mulighed for at sammensætte vores egne markeringstag uden at skulle ringe til browserproducenten.
HTML er meget displaycentreret
HTML er et godt sprog til visningsformål, medmindre du har brug for en masse præcis formatering eller transformationskontrol (i hvilket tilfælde det stinker). HTML repræsenterer en blanding af dokumentets logiske struktur (titler, afsnit og lignende) med præsentationskoder (fed, billedjustering og så videre). Da næsten alle HTML-tags har at gøre med, hvordan man viser information i en browser, er HTML ubrugelig til andre almindelige netværksapplikationer - som datareplikering eller applikationstjenester. Vi har brug for en måde at forene disse almindelige funktioner med display, så den samme server, der bruges til at gennemse data, kan f.eks. Også udføre forretningsfunktioner og interoperere med ældre systemer.
HTML kan normalt ikke genbruges direkte
Oprettelse af dokumenter i tekstbehandlingsprogrammer og derefter eksport af dem som HTML er noget automatiseret, men kræver i det mindste i det mindste noget tilpasning af output for at opnå acceptable resultater. Hvis de data, som dokumentet blev produceret af, ændres, skal hele HTML-oversættelsen foretages igen. Websteder, der viser det aktuelle vejr rundt om i kloden, døgnet rundt, håndterer normalt denne automatiske omformatering meget godt. Dokumentets indhold og præsentationsstil adskilles, fordi systemdesignerne forstår, at deres indhold (temperaturer, prognoser osv.) Ændres konstant. Hvad vi har brug for, er en måde at specificere datapræsentation med hensyn til struktur, så når formateringen opdateres, kan formateringen "genanvendes" konsekvent og let.
HTML giver kun en 'visning' af data
Det er svært at skrive HTML, der viser de samme data på forskellige måder baseret på brugeranmodninger. Dynamisk HTML er en start, men det kræver en enorm mængde scripting og er ikke en generel løsning på dette problem. (Dynamisk HTML diskuteres mere detaljeret nedenfor.) Det, vi har brug for, er en måde at få alle de oplysninger, vi måske ønsker at gennemse på en gang, og se på det på forskellige måder på klienten.
HTML har ringe eller ingen semantisk struktur
De fleste webapplikationer vil drage fordel af en evne til at repræsentere data ved mening snarere end ved layout. For eksempel kan det være meget vanskeligt at finde det, du leder efter på Internettet, fordi der ikke er nogen indikation for betydningen af dataene i HTML-filer (bortset fra META-tags, som normalt er vildledende). Type
rød
ind i en søgemaskine, og du får links til Red Skelton, rød sild, rød snapper, den røde skræmme, Red Letter Day og sandsynligvis en side eller to af "Books I'm Red." HTML har ingen måde at specificere, hvad et bestemt sideelement betyder. Et mere nyttigt markup-sprog vil repræsentere information med hensyn til dets betydning. Hvad vi har brug for er et sprog, der fortæller os ikke, hvordan vi skal
Skærm
information, men snarere, hvad en given informationsblok
er
så vi ved, hvad vi skal gøre med det.

SGML har ingen af disse svagheder, men for at være generel er den hårrivende kompleks (i det mindste i sin fulde form). Det sprog, der bruges til at formatere SGML (dets "stilsprog"), kaldet DSSSL (Document Style Semantics and Specification Language), er ekstremt kraftigt, men svært at bruge. Hvordan får vi et sprog, der er omtrent lige så let at bruge som HTML, men som har det meste af kraften i SGML?

Oprindelsen til XML

Da internettet eksploderede i popularitet, og folk over hele verden begyndte at lære om HTML, begyndte de temmelig hurtigt at løbe ind i de begrænsninger, der er beskrevet ovenfor. Tungmetal-SGML-sår, der havde arbejdet med SGML i årevis i relativ uklarhed, fandt pludselig, at hverdagens mennesker havde en vis forståelse af begrebet markering (dvs. HTML). SGML-eksperter begyndte at overveje muligheden for at bruge SGML på nettet direkte i stedet for kun at bruge en applikation af det (igen HTML). Samtidig vidste de, at SGML, selvom det var stærkt, simpelthen var for kompliceret til at de fleste kunne bruge.

I sommeren 1996 overbeviste Jon Bosak (i øjeblikket online informationsteknologiarkitekt hos Sun Microsystems) W3C om at lade ham danne et udvalg om brug af SGML på nettet. Han skabte et stærkt team af muckety-mucks fra SGML-verdenen. I november samme år havde disse folk skabt begyndelsen på en forenklet form for SGML, der inkorporerede prøvede og sande funktioner i SGML, men med reduceret kompleksitet. Dette var og er XML.

I marts 1997 udgav Bosak sit milepæl, "XML, Java and the Future of the Web" (se Ressourcer). Nu to år senere (meget lang tid på Internettet) er Bosaks korte papir stadig en god, hvis dateret introduktion til, hvorfor brug af XML er en så god idé.

SGML blev oprettet til generel dokumentstrukturering, og HTML blev oprettet som en anvendelse af SGML til webdokumenter. XML er en forenkling af SGML til generel internetbrug.

Et XML-konceptuelt eksempel

Al denne snak om "at opfinde dine egne tags" er ret tåget: Hvilken slags tags vil en udvikler opfinde, og hvordan ville den resulterende XML blive brugt? I dette afsnit gennemgår vi et eksempel, der sammenligner og kontrasterer repræsentation af oplysninger i HTML og XML. I et senere afsnit ("XSL: Jeg kan lide din stil") går vi over XML-visning.

Først tager vi et eksempel på en opskrift og viser den som et muligt HTML-dokument. Derefter gentager vi eksemplet i XML og diskuterer, hvad der køber os.

HTML-eksempel

Se på det lille stykke HTML i liste 1:

Lime Jello Marshmallow Cottage Cheese Surprise

Min bedstemors favorit (må hun hvile i fred).

ingredienser

Antal	Enheder	Vare
1	boks	kalkgelatine
500	g	flerfarvede små skumfiduser
500	ml	hytteost
	streg	Tabasco sauce (valgfri)

Instruktioner

Forbered kalkgelatine i henhold til pakkevejledningen ...

Notering 1. Noget HTML

(En udskrivningsbar version af denne fortegnelse kan findes på eksempel.html.)

Når man ser på HTML-koden i lister 1, er det sandsynligvis klart for næsten alle, at dette er en opskrift på noget (noget forfærdeligt, men alligevel en opskrift). I en browser producerer vores HTML noget som dette:

Lime Jello Marshmallow Cottage Cheese Surprise

Min bedstemors favorit (må hun hvile i fred).

ingredienser

Antal	Enheder	Vare
1	boks	kalkgelatine
500	g	flerfarvede små skumfiduser
500	ml	Hytteost
	streg	Tabasco sauce (valgfri)

Instruktioner

Forbered kalkgelatine i henhold til pakkevejledningen ...

Notering 2. Hvordan HTML i Listing 1 ser ud i en browser

Nu er der en række fordele ved at repræsentere denne opskrift i HTML som følger:

Det er ret læsbart. Markeringen kan være lidt kryptisk, men hvis den er anbragt korrekt, er den ret let at følge.
HTML kan vises af næsten enhver HTML-browser, selv en uden grafikfunktion. Det er et vigtigt punkt: Skærmen er browseruafhængig. Hvis der var et foto af resultaterne af at lave denne opskrift (og man håber bestemt ikke, at det ikke er det), ville det vises i en grafisk browser, men ikke i en tekstbrowser.
Du kan bruge et kaskadestilark (CSS - vi taler lidt om dem nedenfor) til generel kontrol over formatering.

Der er dog et stort problem med HTML som dataformat. Det betyder af de forskellige data i dokumentet går tabt. Det er virkelig svært at tage generel HTML og finde ud af, hvad dataene i HTML betyder. Det faktum, at der er en af denne opskrift med en (mængde) på 500 ml () af hytteost ville være meget svært at udtrække fra dette dokument på en måde, der generelt er meningsfuld.

Nu, ideen om data i et HTML-dokument betyder noget kan være lidt svært at forstå. Websider er fine for den menneskelige læser, men hvis et program skal behandle et dokument, kræver det utvetydige definitioner af, hvad tags betyder. For eksempel tag i et HTML-dokument vedlægger titlen på dokumentet. Det er hvad mærket betyder, og det betyder ikke noget andet. Tilsvarende en HTML tag betyder "tabel række", men det nytter ikke meget, hvis dit program forsøger at læse opskrifter for f.eks. at oprette en indkøbsliste. Hvordan kunne et program finde en liste over ingredienser fra en webside formateret i HTML?

Sikker på, du kunne skrive et program, der griber overskrifterne ud af dokumentet, læser kolonneoverskrifterne i tabellen, finder ud af mængderne og enhederne af hver ingrediens osv. Problemet er, at alle formaterer opskrifter forskelligt. Hvad hvis du forsøger at få disse oplysninger fra f.eks. Julia Childs-webstedet, og hun bliver ved med at rode med formateringen? Hvis Julia ændrer rækkefølgen på kolonnerne eller holder op med at bruge tabeller, bryder hun dit program! (Selvom det skal siges: Hvis Julia begynder at offentliggøre opskrifter som denne, vil hun måske tænke på at skifte karriere.)

Forestil dig nu, at denne opskriftsside kom fra data i en database, og du gerne vil kunne sende disse data rundt. Måske vil du føje det til din enorme opskriftsdatabase derhjemme, hvor du kan søge og bruge den, som du vil. Desværre er dit input HTML, så du skal bruge et program, der kan læse denne HTML, finde ud af, hvad alle "ingredienser", "Instruktioner", "Enheder" osv. Er, og derefter importere dem til din database. Det er meget arbejde. Især da al den semantiske information - igen, betydningen af dataene - eksisterede i den oprindelige database, men blev tilsløret under processen med at blive omdannet til HTML.

Forestil dig nu, at du kunne opfinde dit eget brugerdefinerede sprog til beskrivelse af opskrifter. I stedet for at beskrive, hvordan opskriften skulle vises, ville du beskrive informationsstruktur i opskriften: hvordan hvert stykke information vil relateres til de andre stykker.

XML-eksempel

Lad os bare sammensætte et markup-sprog til beskrivelse af opskrifter og omskrive vores opskrift på det sprog som i Listing 3.

  Lime Jello Marshmallow Cottage Cheese Surprise Min bedstemors favorit (må hun hvile i fred). 1 lime gelatine 500 flerfarvede små skumfiduser 500 hytteost Tabasco sauce Forbered lime gelatine i henhold til pakkevejledningen

Liste 3. Et brugerdefineret markup-sprog til opskrifter

Det vil komme som en lille overraskelse for dig, da du er den kloge læser, at denne opskrift i sit nye format faktisk er et XML-dokument. Måske det faktum, at filen startede med det ulige overskrift

gav det væk; faktisk skal alle XML-filer begynde med denne overskrift. Vi har simpelthen opfundet markup-tags, der har en bestemt betydning; for eksempel "An er en (mængde i specificerede enheder) af en enkelt , hvilket muligvis er valgfri. "Vores XML-dokument beskriver oplysningerne i opskriften med hensyn til opskrifter, i stedet for med hensyn til hvordan Skærm opskriften (som i HTML). Semantikken, eller betydningen af informationen, opretholdes i XML, fordi det er det, tag-sættet blev designet til at gøre.

Noter om notation

Det er vigtigt at få en nomenklatur lige. I figur 1 ser du a start tag, der begynder et lukket tekstområde, kendt som en Vare, ifølge tagnavn. Som i HTML kan XML-tags indeholde en liste over egenskaber (bestående af en attributnavn og en attributværdi.) Det Vare defineret af tag slutter med slutkode.

Ikke hvert tag omslutter tekst. I HTML er

tag betyder "linjeskift" og indeholder ingen tekst. I XML er sådanne elementer ikke tilladt. I stedet har XML det tomme tags betegnet med en skråstreg før den sidste vinkelbeslag i taggen. Figur 2 viser et tomt mærke fra vores XML-opskrift. Bemærk, at tomme tags kan have attributter. Dette tomme tageksempel er standard XML-stenografi til .

Ud over disse notationsforskelle fra HTML er XML's strukturelle regler strengere. Hvert XML-dokument skal være velformet. Hvad betyder det? Læs videre!

Ooh La La! Velformet XML

Begrebet velformet kommer fra matematik: Det er muligt at skrive matematiske udtryk, der ikke betyder noget.For eksempel udtrykket

2 ( + + 5 (=) 9 > 7

ligner (slags) matematik, men det er ikke matematik, fordi det ikke følger de notationsmæssige og strukturelle regler for et matematisk udtryk (i det mindste ikke på denne planet). Med andre ord er "udtrykket" ovenfor ikke velformet. Matematiske udtryk skal være velformede, før du kan gøre noget nyttigt med dem, fordi udtryk, der ikke er velformede, er meningsløse.

Et velformet XML-dokument er simpelthen et, der følger alle de notationelle og strukturelle regler for XML. Programmer, der har til hensigt at behandle XML, skal afvise enhver XML-indgang, der ikke følger reglerne for at være velformeret. De vigtigste af disse regler er som følger:

Ingen lukkede tags
Du kan slippe af sted med alle slags wacko-ting i HTML. For eksempel kan du i de fleste HTML-browsere "åbne" et listeelement med

Ingen overlappende tags
Et tag, der åbnes inde i et andet tag, skal lukkes, inden det indeholdende tag lukkes. For eksempel sekvensen
Lad os afbryde det hele
er ikke velformet fordi åbner inde i men lukker ikke inde i . Den korrekte rækkefølge skal være
Lad os afbryde det hele
Med andre ord skal dokumentets struktur være strengt hierarkisk.
Attributværdier skal være anført i anførselstegn
I modsætning til HTML tillader XML ikke "nøgne" attributværdier (dvs. HTML-tags som f.eks
, hvor der ikke er citater omkring attributværdien). Hver attributværdi skal have anførselstegn ().
Teksttegnene () og (") skal altid være repræsenteret af 'karakterenheder'
For at repræsentere disse tre tegn (venstre vinkelbeslag, vinkelret parentes og dobbelt anførselstegn) i tekstdelen af XML (ikke i markeringen) skal du bruge specialtegnene (
<
), (
>
) og (
"
), henholdsvis. Disse tegn er specialtegn til XML. En XML-fil med f.eks. Det dobbelte anførselstegn i teksten, der er omsluttet af tags i en XML-fil, er ikke velformet, og korrekt designede XML-parsere frembringer en fejl for sådan input.

'Velformet' betyder 'parsable'

En generisk XML parser er et program eller klasse, der kan læse enhver velformet XML ved dens input. Mange leverandører tilbyder nu XML-parsere i Java gratis; (Du finder links til disse pakker i Ressourcer nederst i denne artikel). XML-parsere genkender velformede dokumenter og producerer fejlmeddelelser (ligesom en compiler ville), når de modtager input, der ikke er velformeret. Som vi vil se, er denne funktionalitet meget praktisk for programmøren: Du kalder simpelthen den parser, du har valgt, og den tager sig af fejlregistreringen og så videre. Mens alle XML-parsere kontrollerer, om dokumenterne er velformede (hvilket betyder, som vi har set, at alle tags giver mening, er indlejret korrekt osv.), validering XML-parsere går et skridt videre. Validerende parsere bekræfter også, om dokumentet er gyldig; det vil sige, at strukturen og antallet af tags giver mening.

For eksempel viser de fleste browsere et dokument, der (meningsløst) har to elementer, men hvordan kan dette være? Kun en titel eller ingen titel giver mening.

For et andet eksempel kan du forestille dig, at ingrediens "cottage cheese" i Listing 3 så sådan ud:

  500 9 Hytteost

Dette XML-dokument er bestemt velformet, men det giver ikke mening. Det er det ikke strukturelt gyldig. Det er vrøvl for en at indeholde en <Antal>. Hvad er det? af dette ?

Problemet er, at vi har et godt formet dokument, men det er ikke særlig nyttigt, fordi XML ikke giver mening. Vi har brug for en måde at specificere, hvad der gør et XML-dokument gyldigt. For eksempel, hvordan kan vi specificere, at a tag kan kun indeholde tekst (og ikke andre elementer) og rapportere som fejl i ethvert andet tilfælde?

Svaret på dette spørgsmål ligger i noget kaldet definition af dokumenttype, som vi ser på næste.