|
Sist oppdatert den 7. februar 2002. Dette er en norsk oversettelse av W3C's spesifikasjon "Namespaces in XML" ifra den 14 januar 1999. Arbeidet med oversettingen er utført av Frank Karlstrøm for å øke anvendelsen av XML i Norge. Originaldokumentet på engelsk er den eneste normative referansen. I dette dokumentet er følgende oversettelser av vanlige uttrykk brukt:
|
Kopibeskyttet © 1999 W3C (MIT, INRIA, Keio ), Alle rettigheter forbeholdt. W3C forpliktelser, varemerke, dokument bruk og program lisensierings regler gjelder.
Dette dokumentet har blitt kontrollert av medlemmer i W3C og andre interesserte grupper og har blitt rangert av W3Cs Director som en W3C anbefaling. Det er et stabilt dokument og kan bli brukt som referansemateriale eller henvist til som en normativ referanse ifra et annet dokument. W3Cs rolle i anbefalingen er å fokusere oppmerksomheten mot spesifikasjonen og å fremme en bred anvendelse av den. Dette forbedrer funksjonaliteten og utbyttet på webben.
Listen over kjente feil i denne spesifikasjonen er tilgjengelig på http://www.w3.org/XML/xml-names-19990114-errata.
Vennligst rapporter feil i det engelske originaldokumentet til xml-names-editor@w3.org.
Vennligst rapporter feil i dette norske dokumentet til frank_karlstrom@hotmail.com.
XML navnerom gir en enkel metode for å kvalifisere elementnavn og egenskapsnavn brukt i Extensible Markup Language dokumenter ved å assosiere de med navnerom som identifiseres ved hjelp av URI referanser.
Vi ser for oss programmer i Extensible Markup Language (XML) hvor et enkelt XML dokument kan inneholde elementer og egenskaper (her referert til som "oppmerking") som er definert for og brukt av mange forskjellige programmoduler. Et motiv for dette er modularitet, det vil si hvis det eksisterer en oppmerking som fungerer godt og det finnes programmer som bruker denne, er det bedre å bruke denne oppmerkingen isteden for å finne opp en ny.
Slike dokumenter som inneholder flere oppmerkingsvokabularer kan forårsake i problemer i forbindelse med gjenkjenning og kollisjoner. Program-moduler trenger å kjenne igjen taggene og egenskapene som de er skrevet for å igjenkjenne, selv om "kollisjoner" oppstår når oppmerking som er beregnet for en annen programpakke bruker samme elementtype eller egenskapsnavn.
Dette tilsier at dokumenter bør ha universelle navn, hvor omfanget strekker seg utover dokumentet de befinner seg i. Denne spesifikasjonen beskriver en mekanisme, XML navnerom, hvor dette blir gjort mulig.
[Definisjon:] Et XML navnerom er en samling av navn, identifisert av en URI referanse [RFC2396], som blir brukt i XML dokumenter som elementtyper og egenskapsnavn. XML navnerom er forskjellig ifra de "navnerom" som vanligvis brukes i data-terminologi ved at XML versjonen har en intern struktur og er ikke, ifølge matematiske termer, et sett. Dette er diskutert i "A. Den interne strukturen til XML Navnerom".
[Definisjon:] URI referanser som identifiserer navnerom er sett på som identiske når de er nøyaktig like bokstav for bokstav. Legg merke til at URI referanser som ikke er identiske på denne måten faktisk kan være like med hensyn på funksjonalitet. Eksempler på dette inkluderer URI referanser som har forskjellige små og store bokstaver, eller som er eksterne entiteter som har forskjellige grunn URIer.
Navn ifra XML navnerom kan vises som kvalifiserte navn, som inneholder et enkelt kolon, som deler opp navnet inn i et navneprefiks og en lokal del. Prefikset, som er knyttet til en URI refereranse, velger et navnerom. Kombinasjonen av det universellt definerte URI navnerommet og dokumentet sitt eget navnerom resulterer i identifikatorer som er universellt unike. Det finnes mekanismer for prefiksomfang og standard verdier.
URI referanser kan inneholde bokstaver som ikke er lovlige i navn, så de kan ikke bli brukt direkte som navneromprefikser. Derfor fungerer et navneromprefiks som en logisk peker til en URI referanse. En egenskapsbasert syntaks som er beskrevet under blir brukt til å fastsette koblingen mellom et navneromprefiks og en URI referanse. Programmer som støtter dette navnerommet må kjenne igjen og behandle disse deklarasjonene og prefiksene.
Legg merke til at mange begrep som står i begrepsbeskrivelsene i denne spesifikasjonen ikke er definert her, men i XML spesifikasjonen [XML]. Når begrep som er definert her, har det samme navnet som et begrep definert i XML spesifikasjonen, vil alltid et utsnitt av begrepsbeskrivelsene i denne spesifikasjonen stemme med de korresponderende i XML spesifikasjonen.
I dette dokumentets begrepsbeskrivelser står NSC for "Navnerombegrensning" (Eng: "Namespace Constraint"),
som er en av reglene som alle dokumenter som er i henhold til denne spesifikasjonen må følge.
Legg merke til at alle internett domenenavn som er brukt i eksempler, med unntak av w3.org,
er tilfeldig valgt og skal ikke bli sett på som virkelige eksempler.
[Definisjon:] Et navnerom er
deklarert ved å bruke en familie av reserverte egenskaper.
Navnene til slike egenskaper må enten være xmlns eller ha xmlns: som et prefiks.
Disse egenskapene, slik som en hvilken som helst annen XML egenskap, kan bli gjort tilgjengelig direkte
eller som en standard verdi.
| Egenskapsnavn for navneromdeklarasjon | ||||||||||||||||||||||||||||
|
[Definisjon:] Egenskapens verdi, en URI referanse, er navneromnavnet som identifiserer navnerommet. For at navnerommet skal fungere slik det er ment å fungere, bør det være entydig og persistent. Det er ikke et mål at det skal bli direkte brukt for å hente et skjema (hvis et slikt eksisterer). Et eksempel på en syntax som er designet på grunnlag av disse målene er Uniform Resource Names (URN) [RFC2141]. På den annen side bør man legge merke til at vanlige URL'er kan håndteres på en slik måte at de samme målene blir nådd.
[Definisjon:] Hvis egenskapsnavnet tilsvarer
PrefixedAttName,
så vil
NCName angi navneromprefikset.
Dette navneromprefikset blir brukt til å assosiere elementnavn og egenskapsnavn med
navneromnavnet som er angitt i egenskapsverdien. Assosiasjonen gjelder kun
i omfanget til elementet hvor navneromdeklarasjonen befinner seg.
I slike deklarasjoner kan ikke navneromnavnet være tomt.
[Definisjon:] Hvis egenskapsnavnet tilsvarer
DefaultAttName,
så vil
navneromnavnet i egenskapsverdien bli standard navnerom som vil gjelde
kun i omfanget til elementet hvor deklarasjonen befinner seg.
I slike deklarasjoner kan navneromnavnet være tomt.
Standard navnerom og overstyring av deklarasjoner diskuteres i
"5. Overføring av navnerom til elementer og egenskaper".
Et eksempel på en navneromdeklarasjon, som assosierer navneromprefikset edi
med navneromnavnet http://e-butikk.no/skjema:
<x xmlns:edi='http://e-butikk.no/skjema'> |
Navnerombegrensning:
Starter med "XML"
Prefikser som startet med tre-bokstavs sekvensen x,
m, l, i en hvilken som helst kombinasjon av små og store bokstaver,
er reservert for bruk av XML og XML relaterte spesifikasjoner.
[Definisjon:] I XML dokumenter som er i henhold til
denne spesifikasjonen, kan noen navn (konstruksjoner som tilsvarer begrepet
Name)
bli angitt som kvalifiserte navn, med følgende definisjon:
| Kvalifisert navn | ||||||||||||
|
Prefikset angir
navneromprefiks
delen av det kvalifiserte navnet, og må være assosiert med en navnerom URI referanse i en
navneromdeklarasjon.
[Definisjon:]
LocalPart angir den
lokale delen av det kvalifiserte navnet.
Legg merke til at prefikset fungerer kun som en referanse til et navneromnavn. Programmer bør bruke navneromnavnet, ikke prefikset, når de lager navn hvor omfanget går ut over dokumentet de befinner seg i.
I XML dokumenter som er i henhold til denne spesifikasjonen, er elementtyper representert som kvalifiserte navn, med følgende definisjon:
| Elementtyper | ||||||||||||||||||
|
Et eksempel på en elementtype med et kvalifisert navn:
<x xmlns:edi='http://e-butikk.no/skjema'> |
Egenskaper er enten navneromdeklarasjoner ellers så er navnene representert som kvalifiserte navn:
| Egenskap | ||||||||||
|
Et eksempel på et egenskapsnavn med et kvalifisert navn:
<x xmlns:edi='http://e-butikk.no/skjema'> |
Navnerombegrensning:
Deklarert prefiks
Navneromprefikset, hvis det ikke er xml
eller xmlns, må ha blitt deklarert i en navneromdeklarasjonsegenskap i enten starttaggen av elementet hvor prefikset er brukt,
eller i en av stamforeldreelementene (for eksempel et element hvor den
prefiksede oppmerkingen befinner seg i innholdet).
Prefikset xml er per definisjon bundet til navneromnavnet http://www.w3.org/XML/1998/namespace.
Prefikset xmlns brukes kun til navnerombindinger og
er ikke selv bundet til noe navneromnavn.
Denne begrensningen kan føre til problemer i de tilfeller hvor navneromdeklarasjonsegenskapen ikke er gjort tilgjengelig direkte i XML dokument entiteten, men via en standard egenskap deklarert i en ekstern entitet. Det kan hende at slike deklarasjoner ikke blir lest av programmer basert på XML prosessorer som ikke validerer. Mange XML programmer, formodentlig også navneromsensitive, krever ikke nødvendigvis validerende prosessorer. For at slike programmer skal fungere korrekt, må navneromdeklarasjoner bli gjort tilgjengelige enten direkte, eller via standard egenskaper deklarert i den interne delen av DTD'en.
Elementnavn og egenskapstyper er også angitt som kvalifiserte navn når de befinner seg i deklarasjoner i DTD'en:
| Kvalifiserte navn i deklarasjoner | ||||||||||||||||||||||||||||
|
Navneromdeklarasjonen ansees som overført til elementet hvor det er spesifisert
og til alle elementer i innholdet til dette elementet, hvis det ikke blir overstyrt av en annen
navneromdeklarasjon med samme NSAttName del:
<?xml version="1.0"?> |
Flere navneromprefikser kan bli deklarert som egenskaper til et enkelt element, som vist i dette eksemplet:
<?xml version="1.0"?> |
Standard navnerom ansees som overført til elementet hvor det er deklarert (hvis det elementet ikke har noe navneromprefiks), og til alle elementer uten noe prefiks inne i innholdet til det elementet. Hvis URI referansen i en standard navneromdeklarasjon er tomt, så vil elementer uten prefix i området til deklarasjonen ansees å ikke være i noe navnerom. Legg merke til at standard navnerom ikke overføres direkte til egenskaper.
<?xml version="1.0"?> |
<?xml version="1.0"?> |
Et større eksempel på omfanget til navnerom:
<?xml version="1.0"?> |
Standard navnerom kan bli satt til å være en tom streng. Dette har samme effekten, innenfor området til deklarasjonen, som at det ikke finnes noe standard navnerom.
<?xml version='1.0'?> |
I XML dokumenter som er i henhold til denne spesifikasjonen, er det ingen tagger med to egenskaper som:
For eksempel så er hver enkelt av fysj starttaggene ulovlige i følgende:
<!-- http://www.w3.org er bundet til n1 og n2 --> |
På den annen side så er hver enkelt av de følgende lovlige, den andre fordi standard navnerom ikke blir overført til egenskapsnavnene:
<!-- http://www.w3.org er bundet til n1 og er standard navnerom --> |
I XML dokumenter som er i henhold til denne spesifikasjonen,
må elementtyper og egenskapsnavn tilsvare begrepsbeskrivelsen for
QName
og må tilfredsstille "Navnerombegrensninger".
Et XML dokument er i henhold til denne spesifikasjonen hvis alle nødvendige oppmerkingstegn i dokumentet
tilsvarer denne spesifikasjonens begrepsbeskrivelse av
NCName.
De må i tillegg, for å være i henhold til XML spesifikasjonen, tilsvare XML begrepsbeskrivelsen av
Name
Resultatet av at et dokument er i henhold til denne spesifikasjonen er:
Satt på spissen, så er egenskapsverdier deklarert til å være av typene
ID, IDREF(S), ENTITY(IES),
og NOTATION også Names,
og derfor bør heller ikke de inneholde kolon.
På den annen side så er den deklarerte typen av egenskapsverdier kun tilgjengelig for prosessorer som leser
oppmerkingsdeklarasjoner, for eksempel
validerende prosessorer.
Det vil si at hvis det ikke har blitt spesifisert at en validerende prosessor skal brukes,
finnes det ingen forsikring for at innholdet i egenskapsverdier blir sjekket for brudd i henhold til denne spesifikasjonen.
I dataterminologi rereferer vanligvis "navnerom" til et sett av navn, d.v.s. en samling som ikke inneholder duplikater. På den annen side å behandle navnene som er brukt i XML oppmerking som en slik type navnerom ville ha svekket brukbarheten til slike navnerom betydelig. Den primære bruken av slike navn i XML dokumenter er å muliggjøre identifisering av logiske strukturer i dokumentet av programmoduler slik som forespørselprosessorer, stilarkdrevne tegnemotorer og skjemadrevne validatorer. Se på følgende eksempel:
<seksjon><tittel>Bok-signering</tittel> |
I dette eksempelet det er tre forekomster av navnet tittel
inne i oppmerking, og det er tydelig at navnet alene ikke gir tilstrekkelig informasjon til å tillate
korrekt prosessering av en programmodul.
Et annet problematisk område kommer fra bruken av "globale" egenskaper, som vist i dette eksempelet hvor en del av et XML dokument skal bli vist ved hjelp av et CSS stilark:
<RESERVERING> |
I dette eksempelet er CLASS egenskapen,
som beskriver hva slags type sete reservasjonen har med verdier som "J", "Y" og "C" forskjellige på alle strukturelle nivå ifra
HTML:CLASS egenskapen som er brukt for å simulere
ekstra syntaksfunksjonalitet i HTML.
CLASS egenskapen er brukt til å utvide det begrensede elementforrådet ved å delklassifisere elementet.
XML 1.0 har ingen innebygd måte å deklarere "globale" egenskaper.
Objekter som HTML CLASS egenskapen er globale bare i litteratur-beskrivelser og tolkningen
av HTML programmer. På den annen side så er slike egenskaper, hvor en viktig måte å skille dem ifra hverandre på
er at navnene er unike, veldig vanlig i mange forskjellige programmer.
For å støtte opp om målet om å la både kvalifiserte og ukvalifiserte navn fungere slik det var meningen, identifiserer vi navn som finnes i et XML navnerom til å tilhøre en av flere adskilte tradisjonelle (d.v.s. sett-strukturerte) navnerom, som vi kaller navneromgrupper. Gruppene er:
I XML dokumenter som er i henhold til denne spesifikasjonen, tilhører navnene til alle kvalifiserte (prefiksede) egenskaper "globale egenskaper" gruppen, og navnene til alle ukvalifiserte egenskaper tilhører den riktige "hver enkelt elementtype" gruppe.
For å gjøre det enklere å spesifisere regler og å gjøre sammenligninger, definerer vi en utvidet form, uttrykt her i XML elementsyntaks for hver enkelt elementtype og egenskapsnavn i et XML dokument.
[Definisjon:] En
utvidet elementtype er uttrykt som et tomt XML element av typen
ExpEType.
Den har en nødvendig type egenskap som definerer typens
LocalPart, og en valgfri
ns egenskap som definerer dens
navneromnavn hvis elementet er kvalifisert.
[Definisjon:] Et
utvidet egenskapsnavn er uttrykt som et tomt XML element av typen
ExpAName.
Den har en nødvendig name egenskap som definerer navnet.
Hvis egenskapen er global, har den en nødvendig ns egenskap
som definerer navneromnavnet,
hvis ikke har den en nødvendig eltype egenskap som definerer typen til det vedlagte
elementet, og en valgfri
elns egenskap som definerer navneromnavnet til det vedlagte elementet hvis det er kjent.
Små variasjoner av eksemplene gitt ovenfor vil illustrere hvordan utvidede elementtyper og egenskapsnavn fungerer. De følgende to fragmentene er etterfulgt av en tabell som viser utvidelsen av navnene:
<!-- 1 --> <seksjon xmlns='urn:no:bok-til-alle'> |
Navnene vil utvides som følger:
| Linje | Navn | Utvidet |
| 1 | seksjon | <ExpEType type="seksjon" ns="urn:no:bok-til-alle" /> |
| 2 | tittel | <ExpEType type="tittel" ns="urn:no:bok-til-alle" /> |
| 3 | signering | <ExpEType type="signering" ns="urn:no:bok-til-alle" /> |
| 4 | forfatter | <ExpEType type="forfatter" ns="urn:no:bok-til-alle" /> |
| 4 | tittel | <ExpAName name='tittel' eltype="forfatter" elns="urn:no:bok-til-alle" /> |
| 4 | navn | <ExpAName name='navn' eltype="forfatter" elns="urn:no:bok-til-alle" /> |
| 5 | bok | <ExpEType type="bok" ns="urn:no:bok-til-alle" /> |
| 5 | tittel | <ExpAName name='tittel' eltype="bok" elns="urn:no:bok-til-alle" /> |
| 5 | pris | <ExpAName name='pris' eltype="bok" elns="urn:no:bok-til-alle" /> |
<!-- 1 --> <RESERVERING xmlns:HTML="http://www.w3.org/TR/REC-html40"> |
| 1 | RESERVERING | <ExpEType type="RESERVERING" /> |
| 2 | NAVN | <ExpEType type="NAVN" /> |
| 2 | HTML:CLASS | <ExpAName name="CLASS" ns="http://www.w3.org/TR/REC-html40" /> |
| 3 | SETE | <ExpEType type="SETE" /> |
| 3 | CLASS | <ExpAName name="CLASS" eltype="SETE"> |
| 3 | HTML:CLASS | <ExpAName name="CLASS" ns="http://www.w3.org/TR/REC-html40" /> |
| 4 | HTML:A | <ExpEType type="A" ns="http://www.w3.org/TR/REC-html40" /> |
| 4 | HREF | <ExpAName name="HREF" eltype="A" elns="http://www.w3.org/TR/REC-html40" /> |
| 5 | AVGANG | <ExpEType type="AVGANG" /> |
Begrensningene uttrykt i "5.3 Egenskapenes entydighet" over kan enkelt og greit bli implementert ved å kreve at ingen elementer kan ha to egenskaper hvor de utvidede navnene er like, d.v.s. har de samme egenskapsverdipar.
Dette arbeidet gjenspeiler bidrag fra veldig mange personer, innkludert ikke minst medlemmer av World Wide Web Consortium XML Working Group og Special Interest Group og deltagerne i W3C Metadata Activity. Bidragene av Charles Frankston ifra Microsoft var spesiellt verdifulle.