1 Introduzione
Questa specifica definisce la struttura del linguaggio XML Pointer (XPointer), un sistema estensibile per indirizzamento XML che sottolinea specificazioni addizionali di schema XPointer. Si propone usare la struttura come una base per identificatori di frammenti per qualsiasi risorsa i cui Internet media type siano text/xml, application/xml,
text/xml-external-parsed-entity, o application/xml-external-parsed-entity. Si raccomanda usare questa struttura per altri media type basati in XML, definendo i propri linguaggi di identificatori di frammenti.
Molti tipi di applicazioni di processamento XML hanno bisogno di indirizzarci alla struttura interna delle risorse XML usando referenze URI, ad esempio, lo XML Linking Language [XLink], XML
Inclusions [XInclude], la Resource Description Framework [RDF], e SOAP 1.2 [SOAP12]. Questa specifica non costringe all' uso di tipi di applicazioni che utilizzino referenze URI a risorse XML, né impone il comportamento di queste apliccazioni quando localizzano l' informazione desiderata in quelle risorse.
1.1 Notazione
[Definition: Le parole chiave deve, non deve, richiesto, dovrà, non dovrà, dovrebbe, non dovrebbe, raccomandato, potrebbe e facoltativo in questa specifica si devono interpretare come descritte in [RFC 2119].]
La grammatica formale della Struttura Xpointer si fornisce usando la notazione semplice Extended Backus-Naur Form (EBNF), come si definisce nella Raccomandazione XML [XML].
1.2 Terminologia
- [Definition: pointer ]
-
Una sequenza adatta a questa specifica. Questa specifica definisce la sintassi e la semantica dei cursori.
- [Definition: pointer part ]
-
Una pointer part che provvede un nome di schema e qualche dati pointer di conformità con la definizione di quello schema. Il processore XPointer valuta una pointer part per identificare zero o più subrisorse dentro una risorsa XML.
- [Definition:
scheme ]
-
Un formato specializzato di pointer di dati che ha un nome ed è definito in questa specifica.
- [Definition: XPointer processor ]
-
Un componente software che identifica subrisorse di una risorsa XML applicandone un pointer. Questa specifica definisce il comportamento dei processori XPointer.
- [Definition:
application ]
-
Un componente software che incorpora o usa un processore XPointer perché ha bisogno di accedere a subrisorse XML. L´ apparizione e l´uso dei XPointer, e la condotta ad applicarsi a risorse e subrisorse ottenute tramite il processamento di questi XPointer, sono regolati dalle definizioni del formato di dati corrispondente a ogni applicazione (può essere con base XML o con base non XML). Ad esempio, I Web browser HTML [HTML] e processori che includano X sono applicazioni che possono usare processori XPointer.
- [Definition:
error ]
-
Una violazione delle regole sintattiche di questa specifica, o il fallimento di un pointer nell´ identificazione delle subrisorse.
- [Definition: namespace binding context ]
-
Un vincolo di XML-namespace-defined [XML-Names]
namespace prefissati ai loro nomi namespace associati.
2 Conformità
Questa specifica definisce una struttura; non definisce un livello minimo di conformità per i processori. Perciò, l` informazione di questa sezione definisce i requisiti di conformità soltanto per la parte strutturale di qualsiasi livello minimo di conformità.
I processori XPointer dipendono della capacità delle applicazioni per invertire qualsiasi identificatore di frammento codificato in codici escaping (vedere 4 Caratteri Escaping).
Il comportamento dei processori XPointer dipende della capacità di certa informazione inclusa in una risorsa XML: nei termini provveduti dal [Infoset], gli elementi informativi e proprietà tabulate sotto possono essere importanti. La presenza di alcuni di questi elementi e proprietà dipende del uso di processori con compatibilità DTD o compatibilità XML: i processori con compatibilità XPointer non devono fare questo processamento, ma se lo fanno, il processamento con shorthand pointer approfitterà l' informazione ottenuta (vedere 3.2 Shorthand
Pointer).
I componenti software che intendano essere processori XPointer devono essere conformi con la Struttura XPointerwork specificata in questa raccomandazione o in altre specifiche che, insieme a questa specifica, definiscono il livello minimo di conformità per XPointer, e potrebbero essere conformi alle specifiche addizionali sullo schema XPointer. I processori XPointer devono documentare le specifiche addizionali dello schema con cui sono conformi. Le specifiche che dipendano dal processamento XPointer dovrebbero documentare gli schema richiestiti e sostenuti.
I processori con conformità XPointer devono riportare gli errori di Struttura Xpointer alla applicazione. Le applicazioni sono libere di terminare o ricuperare errori dalla Struttura XPointer in qualsiasi maniera.
3 Linguaggio e Processamento
Questa sezione descrive la Struttura XPointer e il comportamento dei processori XPointer riguardante la struttura.
Un processore XPointer prende come input una risorsa XML e una sequenza per essere usata come pointer (ad esempio, un identificatore di frammento, con escaping inverso, presso dalla referenza URI usata come accesso alla risorsa), tenta di valutare il pointer rispetto alla risorsa, e produce come output un identificatore di subrisorse, o uno o più errori.
3.1 Sintassi
Se una sequenza usata come pointer non aderisce alla sintassi definita in questa sezione, è un errore.
Il simbolo S è definito in [XML]. I simboli NCName e QName sono definiti in [XML-Names].
Sintassi della Struttura XPointer
Come si vede sopra, la fine di una pointer part è segnalata dal carattere parentesi destro ")" che bilancia il carattere parentesi sinistro "(" che inizia la parte. Se appare un parentesi destro o sinistro in uno schema di data senza essere bilanciato dal parentesi contrario, si deve scappare con un carattere circonflesso (^) che lo preceda. Si permettono coppie di parentesi bilanciati. Di fronte a qualsiasi apparizione del circonflesso si deve scappare con un circonflesso addizionale (cioè,^^). Altri usi del circonflesso sono errori.
3.2 Shorthand Pointer
Un shorthand pointer, prima conosciuto come nome vuoto, è un NCName da solo. Identica, come massimo, un elemento nello set di informazione della risorsa; specificamente, il primo (se c`è qualcuno) nell' ordine del documento che abbia un NCName accoppiato come identificatore. Gli identificatori di un elemento si determinato così:
- Se l' item informazione del elemento ha un item informazione del attributo tra i suoi [attributes] è un ID di schema determinato,
perciò viene identificato dal valore di quella proprietà del item informazione del attributo [schema normalized value] ;
-
Se un item informazione del elemento ha un item informazione del elemento tra i suoi [children] è un ID di schema determinato,
perciò viene identificato dal valore di quella proprietà del item informazione del elemento [schema normalized value] ;
-
Se un item informazione del elemento ha un item informazione del attributo tra i suoi [attributes] è un ID DTD-determinato,
perciò viene identificato dal valore di quella proprietà del item informazione del attributo [normalized value].
-
Un item informazione del elemento può anche essere identificato da un valore ID determinato esternamente .
Se non vi è un item informazione del elemento identificato da un NCName, di shorthand pointer, è un errore.
Nota:
Un item informazione del elemento può essere identificato da molti valori in un documento con più di un ID DTD-determinato, ID schema-determinato, e un
ID determinato esternamente. In questi documenti, può accadere una perdita di interoperabilità se i valori identificatori per un elemento determinato non sono sempre uguali.
[Definizione: un item informazione del elemento o del attributo è un ID schema-determinato se:]
-
Ha una proprietà [member type definition] o [type definition]
il cui valore a turno ha [name] uguale a ID e [target namespace] uguale a http://www.w3.org/2001/XMLSchema;
-
Ha una [base type definition] il cui valore ha quello [name]
e [target namespace];
-
Ha una [base type definition] il cui valore ha una [base type
definition] il cui valore ha quel [name] e [target
namespace], e così ricorrentemente inseguendo la proprietà [base type definition];
-
Ha un [type definition name] uguale a ID e un [type definition namespace] uguale a http://www.w3.org/2001/XMLSchema;
- Ha un [member type definition name] uguale a
ID e un [member type definition namespace] uguale a http://www.w3.org/2001/XMLSchema.
[Definizione: un item informazione del attributo è un DTD-determined ID soltanto se ha una proprietà [type definition] il cui valore è uguale a ID.]
[Definizione: un ID determinato esternamente è una sequenza, rappresentando un elemento identificatore, il cui valore viene determinato dall` applicazione di meccanismi fuori lo scopo di questa specifica.]
Nota:
Un shorthand pointer provvede, per risorse con media type basati sul XML, una analogia grossa con il comportamento di un identificatore di frammento HTML. Comunque, se non è disponibile informazione tipo ID perché non è disponibile nessuna informazione specifica DTD, schema o applicazione, il pointer non identificarà nessun elemento. Vi sono molti modi di fare gli identificatori di elementi più affidabili. Per esempio, il creatore di una risorsa può usare uno subset interno DTD per indicare la presenza di attributi tipo ID, e il creatore di un pointer can, invece di un pointer shorthand, può usare un pointer schema-basato o fornire uno o più schema che indirizzino l` elemento desiderato in altri modi.
Nota:
Per le definizione di sopra no è importante se il valore che identifica un item informazione del elemento è unico o no dentro il documento, perché né [XML] né [XMLSchema] richiedono questo per assegnare tipo ID.
3.3 Scheme-Based Pointer
Un Scheme-based pointer è composto di uno o più pointer part, opzionalmente separate da spazi vuoti (S).
Ogni parte ha un nome di schema e contiene, fra parentesi, dati (EscapedData)
conformati con lo schema nominato. Se i dati dello schema contengono parentesi, devono essere bilanciati o scappati.
Quando si forniscono molte pointer part, un processore XPointer deve valutarle in ordine destra-a-sinistra. Se il processore XPointer non sostiene lo schema usato in una pointer part, saltella quella pointer part. Se la pointer part non identifica nessuna sub-risorsa, la valutazione continua con la prossima, se vi è alcuna, pointer part. Il risultato della prima pointer part la cui valutazione identifica una o più subrisorse è riportata dal processore XPointer come risultato del pointer completo, e la valutazione finisce. Se nessuna pointer part identifica subrisorse, è un errore.
Nel esempio seguenti, se la pointer part 'xpointer' non viene capita o fallisce nel identificare qualsiasi subrisorsa, l` 'elemento' pointer part è valutato. Se la pointer part 'xpointer' identifica subrisorse, l 'elementò' pointer part non viene valutato.
#xpointer(id('boy-blue')/horn[1])element(boy-blue/3)Un nome di schema consiste sintatticamente in un Prefisso opzionale e una Parte Locale, secondo la definizione di [XML-Names].
In astratto, i nomi di schema consistono in una Parte Locale e il nome namespace
corrispondente a quel Prefisso nel contesto vincolante namespace. Se il contesto vincolante namespace non contiene il prefisso corrispondente, o se la coppia (nome namespace, Parte Locale) non è corrispondente con un nome di schema che sia sostenuto da un processore XPointer, la pointer part viene saltellata.
Questa specifica riserva tutti I nomi di schema non qualificati per una posteriore definizione in schemi XPointer addizionali a definirsi nelle Raccomandazioni W3C. L`uso di QNames come nomi di schema fornisce una struttura generale per estensibilità ad altri media type basati in XML types che vogliano definire i propri linguaggi di identificatore di frammento con questa struttura. La definizione di qualsiasi schema che si usi insieme con la struttura XPointer deve specificare un nome per lo schema, che sia una coppia (nome namespace, Parte Locale)
.
3.4 Contesto Vincolante Namespace
Le specifiche di schema possono definire modi di vincolare prefissi XML namespaces [XML-Names] a nomi namespace con lo scopo di interpretare i prefissi dei nomi di schema, oppure nomi di elemento, nomi di attributo o altri QNames che appaiano in pointer part. Questi vincoli contribuiscono a un contesto vincolante namespace che si applica a tutte le pointer part alla destra della pointer part che fa il vincolo, a meno che questi schema definiscano eccezioni esplicite. La documentazione di qualsiasi schema vincolante namespace deve specificare se i suoi vincoli restano effettivi per successivi pointer part. La documentazione per ogni schema deve specificare se usa il contesto vincolante namespace.
Nel esempio seguente, lo schema 'xmlns' (vedere [XPtrXmlns]) si usa per aggiungere un vincolo (prefisso/nome namespace) al contesto vincolante namespace. Il processore XPointer usa questa informazione per costatare se img:rect indica il nome di uno schema compatibile.
#xmlns(img=http://example.org/image)img:rect(10,10,50,50)
Il contesto vincolante namespace iniziale prima della valutazione della prima pointer part consiste in una singola entrata: il prefisso xml legato al nome namespace http://www.w3.org/XML/1998/namespace. Il contesto vincolante namespace è sottoposto ai seguenti indicazioni; i tentativi di evitarle non avranno nessun effetto sul contesto vincolante namespace:
-
Il prefisso xml è legato al nome namespace http://www.w3.org/XML/1998/namespace. Non deve essere legato ad altro nome namespace.
-
Il nome namespace http://www.w3.org/XML/1998/namespace è legato al prefisso xml. Non deve essere legato ad altro prefisso.
-
Il prefisso xmlns non deve essere legato a un nome namespace.
-
Il nome namespace http://www.w3.org/2000/xmlns/ non deve essere legato a nessun prefisso.
I prefissi che comincino con la sequenze di tre lettere x, m, l, in qualunque combinazione, sono riservati. Gli utenti non dovrebbero usarle, salvo se vengono definite come specifiche XML o riferite a XML.
4 Character Escaping
Lo set di caratteri per XPointer è [Unicode]. Comunque, il linguaggio XPointer è designato per essere usato nel contesto di referenze URI [RFC 2396] e IRI [IRI], che richiedono la codifica ed escape di certi caratteri. XPointer e referenze IRI che contengano XPointer spesso appaiono in documenti XML ed entità analizzate esternamente, che impongono alcuni requisiti propri di escaping quando la codifica limita il repertorio che può essere usato direttamente. Altri contesti possono richiedere escaping adizionali che si applichino a XPointer. Inoltre, giacché alcuni caratteri sono significanti per il procesamento XPointer, escaping bisogna usare questi caratteri nel suo senso ordinario.
4.1 Contesti Escaping
I seguenti contesti richiedono diversi tipi di escaping per poter essere applicati a XPointers:
- A. Escaping di caratteri XPointer
-
Come si è detto in 3.1 Sintassi,
i parentesi non bilanciati e i circonflessi devono essere scappati.
- B. Escaping e Codifica di caratteri riservati IRI
-
[Definizione: Un Identificatore di Risorse Internazzionalizato,
o IRI è un elemento protocollo che estende la sintassi degli URI ad un repertorio maggiore di caratteri Unicode [Unicode].] Le referenze IRI permettono uno superset di caratteri di escaping completo delle referenze URI, però il segno percentuale (%) deve essere scappato normalmente perché è il carattere usato per scappare in URI e IRI.
Così, quando un pointer viene inserito in una referenza IRI, qualsiasi apparizione del segno percentuale (%) deve essere scappata. Altri caratteri possono essere scappati anche, sebbene non sia raccomandabile. I caratteri si scappano così:
-
Ogni caratteri che si deva escapare si converte in UTF-8 [RFC 2279] come uno o più byte.
-
I byte che risultino si scappano con il meccanismo di escaping URI (cioè, convertiti a %HH, essendo HH la notazione esadecimale del valore del byte).
-
Il carattere originale è sostituito per la sequenza di caratteri risultante.
Ad esempio % diventa %25.
- C. Escaping e Codifica di caratteri riservati URI
-
Le referenze IRI possono convertirsi a referenze URI per consumo dei risolutori URI. I caratteri non permessi nelle referenze URI includono tutti i caratteri non-ASCII, più i caratteri esclusi che vengono elencati nella Sezione 2.4 della [RFC 2396], a eccezione degli segni ordinale (#) e percentuale (%) e i caratteri parentesi quadrati permessi nuovamente nella [RFC
2732]. I caratteri non permessi vengono scappati così:
-
Ogni carattere non permesso si converte in UTF-8 [RFC 2279] come uno o più byte.
-
I byte risultanti si scappano con i meccanismi escaping URI (cioè, convertiti in %HH, essendo HH la notazione esadecimale del valore del byte).
-
Il carattere originale è sostituito dalla sequenza di caratteri risultante.
- D. Escaping XML
-
Se un pointer appare in un documento XML o un` entità analizzata esternamente, qualsiasi carattere non esprimibile nella codifica utilizzata deve essere scappato come referenze di carattere, e ogni carattere che sia significativo per il processore XML deve essere escapato quando appaia usando un meccanismo appropriato come referenze di carattere o refenze di entità. Questo escaping è invertito quando il documento o entità XML sono analizzati. Non è raccomandabile mettere referenze URI (in luogo delle referenze IRI che sono più generali) in documenti in XML. Se per alcuna ragione questo si mostra inevitabile, si usa lo stesso meccanismo di escaping.
Siccome il processore XPointer invertirà soltanto lo escaping di caratteri significativi XPointer (A), l` applicazione deve invertire qualsiasi altra codifica o escaping (come B, C, or D) alla quale sia stato sottoposto il pointer. Se il risultato passato al processore XPointer non è di conformità con le regole di sintassi per Xpointer di questa specifica, è un errore.
4.2 Esempi di Escaping
La tabella seguente mostra lo escaping in alcuni contesti di XPointer che contengano parentesi non bilanciata, segni di virgolette doppie, e spazi. Questi esempi usano lo schema 'xpointer' (vedere [XPtrXPointer]),
perchè permette sequenze letterali nel suo schema di dati.
| Contesto |
Notazione |
| Schema di Dati Iniziale |
Lo schema di dati xpointer come creato inizialmente:
string-range(//P,"my favorite smiley :-)") |
| A. XPointer |
Con la parentesi non bilanciata nello schema di dati scappati, come viene richiesto in questa specifica:
xpointer(string-range(//P,"my favorite smiley :-^)")) |
| B. Pointer in referenza IRI |
Uguale a A (nessun segno percentuale incontrato che richieda escaping):
#xpointer(string-range(//P,"my favorite smiley :-^)")) |
| C. Referenza IRI convertita in riferenza URI |
Con virgolette doppie (%22),
spazi (%20), e circonflessi (%5E) escapati:
#xpointer(string-range(//P,%22my%20favorite%20smiley%20:-%5E)%22)) |
| D. Referenza IRI in documento XML |
Virgolette doppie scappate usando la referenza di entità XML predefinita " entity reference (assumendo che il pointer appare in una referenza IRI in un valore di attributo doppie virgolette:
#xpointer(string-range(//P,"my favorite smiley :-^)")) |
La tabella seguente mostra lo escaping di un XPointer che contiene caratteri accentuati in contesti vari. Il documento XML si presume codificato in US-ASCII, che non permette la apparizione diretta della lettera "é".
| Contesto |
Notazione |
| Schema di dati iniziale |
Lo schema di dati xpointer come creato inizialmente:
|
| A. XPointer |
XPointer (senza circonflessi né parentesi non bilanciati che bisognino essere scappati nel schema di dati):
|
| B. Pointer in referenza IRI |
Uguale a A (nessun segno percentuale che bisogni essere scappato):
|
| C. Referenza IRI convertita in referenza URI |
Con lettere "é" (%C3%A9) scappate:
#xpointer(id('r%C3%A9sum%C3%A9')) |
| D. Referenza IRI in documenti XML |
Rappresentata nella codifica US-ASCII le lettere accentuate sono scappate con referenze caratteri XML:
#xpointer(id('résumé')) |