HTML og World Wide Web er overalt. Som et eksempel på deres allestedsnærværende skal jeg til Mellom-Amerika i påsken i år, og hvis jeg vil, vil jeg kunne surfe på nettet, lese e-posten min og til og med gjøre nettbank fra internettkafeer i Antigua Guatemala og Belize by. (Jeg har ikke tenkt å gjøre det, siden det tar tid fra en dato jeg har med et palme og en romfylt kokosnøtt.)
Og til tross for HTMLs allestedsnærvær og popularitet, er den sterkt begrenset i hva den kan gjøre. Det er greit å spre uformelle dokumenter, men HTML brukes nå til å gjøre ting det aldri ble designet for. Å prøve å designe tunge, fleksible, interoperable datasystemer fra HTML er som å prøve å bygge et hangarskip med hacksager og loddejern: verktøyene (HTML og HTTP) er bare ikke opp til jobben.
Den gode nyheten er at mange av begrensningene for HTML har blitt overvunnet i XML, Extensible Markup Language. XML er lett forståelig for alle som forstår HTML, men det er mye kraftigere. Mer enn bare et markeringsspråk, XML er et metallspråk - et språk som brukes til å definere nye markup-språk. Med XML kan du opprette et språk laget spesielt for applikasjonen eller domenet ditt.
XML vil utfylle, i stedet for å erstatte, HTML. Mens HTML brukes til formatering og visning av data, representerer XML den kontekstuelle betydningen av dataene.
Denne artikkelen vil presentere historikken til markup språk og hvordan XML ble til. Vi ser på eksempeldata i HTML og beveger oss gradvis inn i XML, og viser hvorfor det gir en overlegen måte å representere data på. Vi vil utforske årsakene til at du trenger å oppfinne et tilpasset markeringsspråk, og jeg vil lære deg hvordan du gjør det. Vi vil dekke det grunnleggende om XML-notasjon, og hvordan du viser XML med to forskjellige typer stilspråk. Deretter dykker vi inn i Document Object Model, et kraftig verktøy for å manipulere dokumenter som objekter (eller manipulere objektstrukturer som dokumenter, avhengig av hvordan du ser på det). Vi går gjennom hvordan du skriver Java-programmer som trekker ut informasjon fra XML-dokumenter, med en peker til et gratis program som er nyttig for å eksperimentere med disse nye konseptene. Til slutt vil vi ta en titt på et Internett-selskap som baserer sin kjerneteknologistrategi på XML og Java.
Er XML noe for deg?
Selv om denne artikkelen er skrevet for alle som er interessert i XML, har den et spesielt forhold til JavaWorld serie på XML JavaBeans. (Se Ressurser for lenker til relaterte artikler.) Hvis du har lest den serien og ikke helt "får den", bør denne artikkelen avklare hvordan du bruker XML med bønner. Hvis du er for å få det, fungerer denne artikkelen som den perfekte følgesvenn for XML JavaBeans-serien, siden den dekker emner som er urørt der. Og hvis du er en av de få heldige som fremdeles har XML JavaBeans-artiklene å se frem til, anbefaler jeg at du først leser denne artikkelen som innledende materiale.
Et notat om Java
Det er så mye nyere XML-aktivitet i datamaskinverdenen at selv en artikkel av denne lengden bare kan skumme overflaten. Likevel er poenget med denne artikkelen å gi deg konteksten du trenger for å bruke XML i Java-programdesignene dine. Denne artikkelen dekker også hvordan XML fungerer med eksisterende webteknologi, siden mange Java-programmerere jobber i et slikt miljø.
XML åpner internett- og Java-programmering for bærbar funksjonalitet uten nettleser. XML frigjør Internett-innhold fra nettleseren på omtrent samme måte som Java frigjør programadferd fra plattformen. XML gjør Internett-innhold tilgjengelig for ekte applikasjoner.
Java er en utmerket plattform for bruk av XML, og XML er en enestående datarepresentasjon for Java-applikasjoner. Jeg vil påpeke noen av Java's styrker med XML når vi går videre.
La oss begynne med en historieleksjon.
Opprinnelsen til markup språk
HTML-en som vi alle kjenner og elsker (vel, det vet vi uansett) ble opprinnelig designet av Tim Berners-Lee hos CERN (le Conseil Européen pour la Recherche Nucléaire, eller det europeiske laboratoriet for partikkelfysikk) i Genève for å tillate fysikknerds (og til og med ikke-nerds) å kommunisere med hverandre. HTML ble utgitt i desember 1990 innen CERN, og ble offentlig tilgjengelig sommeren 1991 for oss andre. CERN og Berners-Lee ga bort spesifikasjonene for HTML, HTTP og URL-er, i den fine gamle tradisjonen med å dele og nyte Internett.
Berners-Lee definerte HTML i SGML, Standard Generalized Markup Language. SGML, i likhet med XML, er en metaspråk - et språk som brukes til å definere andre språk. Hvert så definerte språk kalles et applikasjon av SGML. HTML er en applikasjon av SGML.
SGML kom frem fra forskning som ble gjort hovedsakelig hos IBM om tekstdokumentrepresentasjon på slutten av 60-tallet. IBM opprettet GML ("General Markup Language"), et forgjengerspråk for SGML, og i 1978 opprettet American National Standards Institute (ANSI) sin første versjon av SGML. Den første standarden ble utgitt i 1983, med utkastet til standarden utgitt i 1985, og den første standarden ble utgitt i 1986. Interessant nok ble den første SGML-standarden utgitt ved hjelp av et SGML-system utviklet av Anders Berglund hos CERN, organisasjonen som, som vi har sett, ga oss HTML og nettet.
SGML er mye brukt i store bransjer og myndigheter som i store luftfarts-, bil- og telekommunikasjonsselskaper. SGML brukes som dokumentstandard ved USAs forsvarsdepartement og Internal Revenue Service. (For lesere utenfor USA er skattemyndighetene skattegutta.)
Albert Einstein sa at alt skulle gjøres så enkelt som mulig, og ikke enklere. Årsaken til at SGML ikke finnes flere steder, er at den er ekstremt sofistikert og kompleks. Og HTML, som du finner overalt, er veldig enkelt; for mange applikasjoner er det for enkelt.
HTML: All form og ingen substanser
HTML er et språk designet for å "snakke om" dokumenter: overskrifter, titler, bildetekster, skrifter og så videre. Det er tungt dokumentstruktur- og presentasjonsorientert.
Riktignok har artister og hackere kunnet gjøre mirakler med det relativt kjedelige verktøyet kalt HTML. Men HTML har alvorlige ulemper som gjør det dårlig egnet til å designe fleksible, kraftige, evolusjonære informasjonssystemer. Her noen av de største klagene:
HTML kan ikke utvides
Et utvidbart markeringsspråk vil tillate applikasjonsutviklere å definere egendefinerte koder for applikasjonsspesifikke situasjoner. Med mindre du er en 600 pund gorilla (og kanskje ikke engang da), kan du ikke kreve at alle nettleserprodusenter implementerer alle markeringskodene som er nødvendige for applikasjonen din. Så du sitter fast med hva de store nettleserprodusentene, eller W3C (World Wide Web Consortium) lar deg få. Det vi trenger er et språk som lar oss lage våre egne merkelapper uten å ringe nettleserprodusenten.
HTML er veldig visningssentrert
HTML er et fint språk for visningsformål, med mindre du trenger mye presis formatering eller transformasjonskontroll (i så fall stinker det). HTML representerer en blanding av dokumentets logiske struktur (titler, avsnitt og lignende) med presentasjonskoder (fet skrift, justering av bilder og så videre). Siden nesten alle HTML-kodene har å gjøre med hvordan du viser informasjon i en nettleser, er HTML ubrukelig for andre vanlige nettverksapplikasjoner - som datareplikering eller applikasjonstjenester. Vi trenger en måte å forene disse vanlige funksjonene med skjerm, slik at den samme serveren som brukes til å bla gjennom data, for eksempel også kan utføre forretningsfunksjoner og samarbeide med eldre systemer.
HTML er vanligvis ikke direkte gjenbrukbar
Å lage dokumenter i tekstbehandlere og deretter eksportere dem som HTML er noe automatisert, men krever likevel i det minste noe finjustering av utdataene for å oppnå akseptable resultater. Hvis dataene som dokumentet ble produsert fra endres, må hele HTML-oversettelsen gjøres om. Nettsteder som viser det aktuelle været over hele kloden, døgnet rundt, takler vanligvis denne automatiske omformateringen veldig bra. Innholdet og presentasjonsstilen til dokumentet er skilt, fordi systemdesignerne forstår at innholdet deres (temperaturene, prognosene og så videre) endres stadig. Det vi trenger er en måte å spesifisere datapresentasjon med tanke på struktur, slik at når data oppdateres, kan formateringen "på nytt" konsistent og enkelt.
HTML gir bare en "visning" av data
Det er vanskelig å skrive HTML som viser de samme dataene på forskjellige måter basert på brukerforespørsler. Dynamisk HTML er en start, men det krever enormt mye skripting og er ikke en generell løsning på dette problemet. (Dynamisk HTML blir diskutert mer detaljert nedenfor.) Det vi trenger er en måte å få all informasjonen vi kanskje vil bla i på en gang, og se på den på forskjellige måter på klienten.
HTML har liten eller ingen semantisk struktur
De fleste webapplikasjoner vil ha nytte av muligheten til å representere data ved mening snarere enn ved layout. For eksempel kan det være veldig vanskelig å finne det du leter etter på Internett, fordi det ikke er noen indikasjon på betydningen av dataene i HTML-filer (bortsett fra META-koder, som vanligvis er misvisende). Type
rød
inn i en søkemotor, og du får lenker til Red Skelton, rød sild, red snapper, den røde skremmen, Red Letter Day, og sannsynligvis en side eller to av "Books I'm Red." HTML har ingen måte å spesifisere hva et bestemt sideelement betyr. Et mer nyttig markup-språk vil representere informasjon når det gjelder betydningen. Det vi trenger er et språk som forteller oss ikke hvordan vi skal
vise
informasjon, men heller hva en gitt informasjonsblokk
er
så vi vet hva vi skal gjøre med det.
SGML har ingen av disse svakhetene, men for å være generelle er det hårrivende komplekst (i det minste i fullstendig form). Språket som brukes til å formatere SGML ("stilsspråk"), kalt DSSSL (Document Style Semantics and Specification Language), er ekstremt kraftig, men vanskelig å bruke. Hvordan får vi et språk som er omtrent like enkelt å bruke som HTML, men som har mest av SGML?
Opprinnelsen til XML
Da nettet eksploderte i popularitet og folk over hele verden begynte å lære om HTML, begynte de ganske raskt å komme inn i begrensningene som er beskrevet ovenfor. Tungmetall SGML-vinner, som hadde jobbet med SGML i årevis i relativt uklarhet, fant plutselig at hverdagslige mennesker hadde en viss forståelse av begrepet markering (det vil si HTML). SGML-eksperter begynte å vurdere muligheten for å bruke SGML på nettet direkte, i stedet for å bruke bare en applikasjon av den (igjen, HTML). Samtidig visste de at SGML, selv om det var kraftig, ganske enkelt var for komplisert for folk flest å bruke.
Sommeren 1996 overbeviste Jon Bosak (for tiden online informasjonsteknologiarkitekt hos Sun Microsystems) W3C om å la ham danne en komité for bruk av SGML på nettet. Han opprettet et kraftig team av muckety-mucks fra SGML-verdenen. I november samme år hadde disse menneskene opprettet begynnelsen på en forenklet form for SGML som innarbeidet prøvde og sanne funksjoner i SGML, men med redusert kompleksitet. Dette var og er XML.
I mars 1997 ga Bosak ut sin milepæl, "XML, Java and the Future of the Web" (se Resources). Nå, to år senere (veldig lang tid i nettets liv), er Bosaks korte papir fremdeles en god, hvis datert, introduksjon til hvorfor bruk av XML er en så utmerket idé.
SGML ble opprettet for generell dokumentstrukturering, og HTML ble opprettet som en applikasjon av SGML for nettdokumenter. XML er en forenkling av SGML for generell nettbruk.
Et XML-konseptuelt eksempel
Alt dette snakket om å "finne opp dine egne koder" er ganske tåkete: Hva slags koder vil en utvikler oppfinne og hvordan vil den resulterende XML bli brukt? I denne delen vil vi gå gjennom et eksempel som sammenligner og kontrasterer informasjonsrepresentasjon i HTML og XML. I en senere seksjon ("XSL: Jeg liker stilen din") går vi over XML-visning.
Først tar vi et eksempel på en oppskrift og viser den som et mulig HTML-dokument. Deretter vil vi gjøre om eksemplet i XML og diskutere hva som kjøper oss.
HTML-eksempel
Ta en titt på den lille biten av HTML i Listing 1:
Lime Jello Marshmallow Cottage Cheese SurpriseLime Jello Marshmallow Cottage Cheese Surprise
Min bestemors favoritt (må hun hvile i fred).Ingredienser
| Antall | Enheter | Punkt |
|---|---|---|
| 1 | eske | kalkgelatin |
| 500 | g | flerfarget bittesmå marshmallows |
| 500 | ml | cottage cheese |
| bindestrek | Tabascosaus (valgfritt) |
Bruksanvisning
- Tilbered kalkgelatin i henhold til pakningsinstruksjonene ...
Oppføring 1. Noe HTML
(En utskriftsversjon av denne oppføringen finner du på example.html.)
Ser vi på HTML-koden i oppføring 1, er det sannsynligvis klart for omtrent alle at dette er en oppskrift på noe (noe forferdelig, men en oppskrift likevel). I en nettleser produserer HTML-en vår noe slikt:
Lime Jello Marshmallow Cottage Cheese SurpriseMin bestemors favoritt (må hun hvile i fred).Ingredienser
Bruksanvisning
|
Oppføring 2. Hvordan HTML i oppføring 1 ser ut i en nettleser
Nå er det en rekke fordeler ved å representere denne oppskriften i HTML, som følger:
Det er ganske lesbart. Markeringen kan være litt kryptisk, men hvis den er ordentlig lagt ut, er den ganske enkel å følge.
HTML-en kan vises av omtrent hvilken som helst HTML-nettleser, til og med en uten grafikkfunksjon. Det er et viktig poeng: Skjermen er nettleseruavhengig. Hvis det var et bilde av resultatene av å lage denne oppskriften (og man håper absolutt ikke at den ikke er), ville den vises i en grafisk nettleser, men ikke i en tekstleser.
- Du kan bruke et cascading style sheet (CSS - vi snakker litt om de nedenfor) for generell kontroll over formatering.
Det er imidlertid et stort problem med HTML som dataformat. De betydning av de forskjellige dataene i dokumentet går tapt. Det er veldig vanskelig å ta generell HTML og finne ut hva dataene i HTML betyr. Det faktum at det er en av denne oppskriften med en (mengde) på 500 ml () av cottage cheese ville være veldig vanskelig å trekke ut fra dette dokumentet på en måte som generelt er meningsfull.
Nå, ideen om data i et HTML-dokument betyr noe kan være litt vanskelig å forstå. Nettsider er bra for den menneskelige leseren, men hvis et program skal behandle et dokument, krever det entydige definisjoner av hva kodene betyr. For eksempel tag i et HTML-dokument vedlegger tittelen på dokumentet. Det er hva taggen betyr, og det betyr ikke noe annet. Tilsvarende en HTML
Visst, du kan skrive et program som tar overskriftene ut av dokumentet, leser tabellkolonneoverskriftene, finner ut mengdene og enhetene til hver ingrediens, og så videre. Problemet er at alle formaterer oppskrifter annerledes. Hva om du prøver å få denne informasjonen fra, for eksempel, Julia Childs-nettstedet, og hun fortsetter å rote med formateringen? Hvis Julia endrer rekkefølgen på kolonnene eller slutter å bruke tabeller, bryter hun programmet ditt! (Selv om det må sies: Hvis Julia begynner å publisere oppskrifter som dette, vil hun kanskje tenke på å endre karriere.)
Tenk deg at denne oppskriftssiden kom fra data i en database, og at du vil kunne sende disse dataene rundt. Kanskje du vil legge den til i den enorme oppskriftsdatabasen hjemme, hvor du kan søke og bruke den slik du vil. Dessverre er innspillene dine HTML, så du trenger et program som kan lese denne HTML-en, finne ut hva alle "ingrediensene", "instruksjonene", "enhetene" og så videre, og deretter importere dem til databasen din. Det er mye arbeid. Spesielt siden all den semantiske informasjonen - igjen, betydningen av dataene - fantes i den opprinnelige databasen, men ble skjult i ferd med å bli transformert til HTML.
Tenk deg at du kan finne på ditt eget tilpassede språk for å beskrive oppskrifter. I stedet for å beskrive hvordan oppskriften skulle vises, vil du beskrive informasjonsstruktur i oppskriften: hvordan hver informasjon vil forholde seg til de andre delene.
XML-eksempel
La oss bare lage et markeringsspråk for å beskrive oppskrifter, og omskrive oppskriften vår på det språket, som i Listing 3.
Lime Jello Marshmallow Cottage Cheese Surprise Min bestemors favoritt (må hun hvile i fred). 1 limegelatin 500 flerfarget små marshmallows 500 cottage cheese Tabascosaus Tilbered limegatin i henhold til pakningsinstruksjonene
Oppføring 3. Et tilpasset merkespråk for oppskrifter
Det vil komme som en liten overraskelse for deg, som den kloke leseren du er, at denne oppskriften i sitt nye format faktisk er et XML-dokument. Kanskje det faktum at filen startet med den merkelige overskriften
ga det bort; faktisk skal alle XML-filer begynne med denne overskriften. Vi har ganske enkelt oppfunnet markeringstagger som har en spesiell betydning; for eksempel "An er en (antall i spesifiserte enheter) av en enkelt , som muligens er valgfri. "Vårt XML-dokument beskriver informasjonen i oppskriften når det gjelder oppskrifter, i stedet for når det gjelder hvordan vise oppskriften (som i HTML). Semantikken, eller betydningen av informasjonen, opprettholdes i XML fordi det er det tag-settet ble designet for å gjøre.
Merknader om notasjon
Det er viktig å få litt nomenklatur rett. I figur 1 ser du a start tag, som begynner et lukket område med tekst, kjent som en Punkt, ifølge taggenavn. Som i HTML, kan XML-koder inneholde en liste over attributter (bestående av en attributtnavn og en attributtverdi.) Den Punkt definert av taggen ender med sluttmerke.
Ikke alle tagger inneholder tekst. I HTML er tag betyr "linjeskift" og inneholder ingen tekst. I XML er slike elementer ikke tillatt. I stedet har XML tomme koder, betegnet med en skråstrek før den siste rettvinklede braketten i merkelappen. Figur 2 viser en tom tag fra vår XML-oppskrift. Merk at tomme koder kan ha attributter. Dette tomme taggeksemplet er standard XML-stenografi for .
I tillegg til disse notasjonsforskjellene fra HTML, er strukturelle regler for XML strengere. Hvert XML-dokument må være velformet. Hva betyr det? Les videre!
Ooh-la-la! Velformet XML
Begrepet velformet kommer fra matematikk: Det er mulig å skrive matematiske uttrykk som ikke betyr noe.For eksempel uttrykket
2 ( + + 5 (=) 9 > 7
ser ut som slags matematikk, men det er ikke matematikk fordi den ikke følger de notasjonelle og strukturelle reglene for et matematisk uttrykk (ikke i det minste på denne planeten). Med andre ord er ikke "uttrykket" ovenfor det velformet. Matematiske uttrykk må være godt formet før du kan gjøre noe nyttig med dem, fordi uttrykk som ikke er velformede, er meningsløse.
Et godt utformet XML-dokument er ganske enkelt et som følger alle de notasjonelle og strukturelle reglene for XML. Programmer som har til hensikt å behandle XML, bør avvise enhver XML-inngang som ikke følger reglene for å være godt utformet. De viktigste av disse reglene er som følger:
Ingen lukkede koder
Du kan komme unna med alle slags wacko-ting i HTML. I de fleste HTML-nettlesere kan du for eksempel "åpne" et listeelement med
og aldri "lukke" den med. Nettleseren finner bare ut hvorville være og setter den automatisk inn for deg. XML tillater ikke denne typen slurv. Hver start-tag må ha en tilsvarende slutt-tag. Dette er fordi en del av informasjonen i en XML-fil har å gjøre med hvordan forskjellige informasjonselementer forholder seg til hverandre, og hvis strukturen er tvetydig, er også informasjonen det. Så, XML tillater ganske enkelt ikke tvetydig struktur. Denne entydige strukturen gjør det også mulig å behandle XML-dokumenter som datastrukturer (trær), som jeg vil forklare kort i diskusjonen om Document Object Model.Ingen overlappende koder
En tag som åpnes inne i en annen tag, må lukkes før den inneholder taggen lukkes. For eksempel sekvensen
La oss slå av det hele
er ikke velformet fordi
åpner innsiden avmen lukker ikke innsiden av. Riktig sekvens må væreLa oss slå av det hele
Dokumentets struktur må med andre ord være strengt hierarkisk.
Attributtverdier må være vedlagt anførselstegn
I motsetning til HTML tillater XML ikke "nakne" attributtverdier (dvs. HTML-koder som
Teksttegnene () og (") må alltid være representert av" tegnenheter "
For å representere disse tre tegnene (venstre vinkel, parentes og doble anførselstegn) i tekstdelen av XML (ikke i markeringen), må du bruke spesialtegnene (
<), (
>), og (
"), henholdsvis. Disse tegnene er spesialtegn for XML. En XML-fil med for eksempel det dobbelte anførselstegnet i teksten som er lukket i koder i en XML-fil, er ikke godt utformet, og riktig utformede XML-parsere vil gi en feil for slik inndata.
'Velformet' betyr 'parsable'
En generisk XML parser er et program eller en klasse som kan lese hvilken som helst velformet XML ved inngangen. Mange leverandører tilbyr nå XML-parsere i Java gratis; (Du finner lenker til disse pakkene i Ressurser nederst i denne artikkelen). XML-parsere gjenkjenner velformede dokumenter og produserer feilmeldinger (omtrent som en kompilator ville gjort) når de mottar inngang som ikke er godt formet. Som vi får se, er denne funksjonaliteten veldig nyttig for programmereren: Du ringer bare parseren du har valgt, og den tar seg av feiloppdagelsen og så videre. Mens alle XML-parsere sjekker dokumentasjonenes velformede form (som, som vi har sett, at alle kodene gir mening, er nestet riktig, og så videre), validering XML-parsere går et skritt videre. Validerende parsere bekrefter også om dokumentet er gyldig; det vil si at strukturen og antall tagger gir mening.
For eksempel vil de fleste nettlesere vise et dokument som (uten mening) har to elementer, men hvordan kan dette være? Bare en tittel eller ingen tittel gir mening.
For et annet eksempel, forestill deg at ingrediens "cottage cheese" i Listing 3 så slik ut:
500 9 Hytteost
Dette XML-dokumentet er absolutt godt formet, men det gir ikke mening. Det er det ikke strukturelt gyldig. Det er tull for en å inneholde en <Antall>. Hva er det? av denne ?
Problemet er at vi har et dokument som er godt utformet, men det er ikke veldig nyttig fordi XML ikke gir mening. Vi trenger en måte å spesifisere hva som gjør et XML-dokument gyldig. Hvordan kan vi for eksempel spesifisere at a tag kan bare inneholde tekst (og ikke andre elementer) og rapportere som feil andre tilfeller?
Svaret på dette spørsmålet ligger i noe som heter definisjon av dokumenttype, som vi skal se på neste.
