2011-11-19 18 views
8

Per another question Ho creato un codice correlato XML che funziona sulla mia macchina di sviluppo ma non su viper codepad dove l'ho testato prima di aggiungerlo alla mia risposta.Ordine risultato query XPath

Potrei ridurre il mio problema al punto che l'ordine dei nodi restituito da DOMXPath::query() differisce tra il mio sistema e il codificatore.

XML: <test>This is some <span>text</span>, fine.</test>

Quando interrogo tutti textnodes //child::text() il risultato è diverso:

Viper Codepad:

#0: This is some 
#1: , fine. 
#2: text 

My Machine:

#0: This is some 
#1: text 
#2: , fine. 

Non sono così esperto con xpath che capisco perché questo accade e come sia probabilmente possibile influenzare l'ordine di restituzione con l'implementazione di PHP.

Edit:

Ulteriori test hanno rivelato che LIBXML_VERSION differisce tra i due sistemi:

Viper Codepad: 20626 (2.6.26; 6 Jun 2006) 
My Machine...: 20707 (2.7.7; 15 Mar 2010) 

risposta

2

Sembra un bug nel 20626 Versione:

E elaborare prima tutto il testo bambino nodi nell'ordine del documento, quindi il contenuto dei nodi elemento figlio. Dovrebbe essere il risultato sulla vostra macchina

+1

Mentre questa è la spiegazione più probabile secondo Occam, ci dovrebbe essere una segnalazione di bug o un indicatore nel log delle modifiche di libxml per verificarlo. – Gordon

+0

Da dove hai ottenuto queste informazioni? Se puoi, per favore aggiungi un link ad alcune risorse ufficiali per favore. – hakre

+0

Era solo il mio presupposto che si tratta di un problema, perché xpath genera un ordine errato dei nodi. Al momento ho trovato solo [questo] (http://mail.gnome.org/archives/xml/2008-November/msg00112.html), ma non è correlato. E probabilmente [questo] (http://mail.gnome.org/archives/xml/2005-May/msg00035.html) anche – Vitaliy

1

Sembra che Viper Codepad non stia restituendo i nodi selezionati text() nel primo ordine di documento, ma facendo una prima valutazione di larghezza.

Si suppone che sia un primo attraversamento di profondità.

Saxon, MSXML, Altova XML hanno restituito i risultati in ordine di profondità.

2

XPath è un linguaggio di query, quindi dovrebbe solo leggere la struttura del documento .xml così com'è e non modificarlo mai. Questo include l'ordine del nodo. Nel tuo primo esempio, tuttavia, questo non è vero. Quindi questo è sicuramente un bug secondo lo this.

+0

Sì, questo è quello che penso anch'io, o almeno come ho capito il termine * Ordine del documento * nella definizione xpath. – hakre

7

Tecnicamente XPath 1.0 restituisce i set di nodi anziché le sequenze di nodi. Nella specifica XPath 1.0 non c'è alcuna dichiarazione sull'ordine di questi set di nodi: infatti, essendo insiemi, non hanno un ordine intrinseco.

Tuttavia, XSLT 1.0 elabora sempre il nodo-set restituiti da XPath 1.0 nell'ordine del documento, ed a causa di tale precedente, v'è una diffusa aspettativa che i risultati XPath saranno in ordine documento quando XPath viene richiamato da lingue diverse XSLT . Tuttavia, non c'è nulla nelle specifiche per garantire questo. In XPath 2.0 l'aspettativa dell'utente diventa parte della specifica e i risultati di un'espressione di percorso DEVONO essere nell'ordine del documento.

+0

+1 per una risposta corretta e informativa. –

+0

libxml2 segue la convenzione di progettazione per tornare sempre nell'ordine del documento. Anche per gli attributi, ad esempio, che non hanno bisogno di avere un ordine. – hakre

+1

@ Michael Kay: che dire dell'ordine con i predicati? XPath 1.0 non specifica che i set di nodi sono nell'ordine del documento? http://www.w3.org/TR/xpath/#predicates – hakre

Problemi correlati