Ciao,
un documento XML può essere interrogato proprio come un database. A parte la natura gerarchica dei dati XML, la differenza è che al posto del linguaggio SQL si usa XPath.
Qui trovi un'introduzione alla sintassi:
http://www.w3schools.com/xpath/xpath_syntax.asp

karontenero ha scritto:

Mi piacerebbe indicare alla mia applicazione da che nodo figlio ricavare i dati da elaborare

Ok, la tua applicazione potrà fornire una stringa XPath come "provincia/comune" per selezionare tutti i nodi "comune" che siano diretti discendenti di "provincia".

Oppure potrà fare delle ricerche. Passando "//provincia[starts-with(@nome, "P")]", potrà ottenere tutti i nodi "provincia", ovunque si trovino, il cui attributo "nome" inizia per "P".

Se invece non ti interessa lavorare direttamente con i nodi XML, ma ti piacerebbe programmare con un modello orientato agli oggetti, allora puoi lasciar perdere XPath e dare un'occhiata a Linq to XML. Se già conosci la sintassi di interrogazione Linq, accedere ai dati sarà più semplice. Ecco la stessa ricerca di prima in Linq To XML. Forse questa è un po' più espressiva e mi dà anche la possibilità di proiettare i nodi risultanti su un mio tipo "Provincia".


Qui hai un video di Stefano Mostarda su Linq to XML, molto informativo.
http://media.aspitalia.com/screencast/LINQ-to-XML-introduzione.media

Qui invece c'è un articolo che mette a confronto i due approcci.
http://msdn.microsoft.com/it-it/library/bb675156.aspx

ciao

---

Modificato da BrightSoul il 23 giugno 2013 13.53 -

ciao,

karontenero ha scritto:

vedo in una lista tutto il conenuto del canale, ma non riesco a specificare il tipo di giorno.

ok, la tua query restituisce il canale giusto, è un buon inizio. Bisogna continuarla andando ad interrogare i suoi TipoGiorno e infine leggere i suoi nodi ora.

Prova così:

Qui vedi in azione il metodo SelectMany, che serve a generare molteplici risultati (da 0 a n) per ogni elemento dell'insieme. Il caso è quello dei tanti elementi ora che scaturiscono da ogni TipoGiorno.

ciao

ciao,
karontenero ha scritto:

Quindi tramite questa query mi ricavo la lista dei valori di start, giusto?

sì, esatto. Hai già provato, funziona?

karontenero ha scritto:

mi viene restituito questo, come mai?

Prova a poggiare il mouse sull'ultimo metodo Select: vedrai che il suo tipo di ritorno è un IEnumerable<string>.
E' perfetto così, perché si tratta di un elenco di stringhe che potrai ciclare un foreach oppure usarlo come data source per qualche controllo.

In realtà, il tipo di oggetto che Select ritorna, non è esattamente un IEnumerable<string> perché IEnumerable è solo un'interfaccia, ovvero un "contratto" che i tipi concreti possono implementare.
Non potendo fare new IEnumerable<string>(), il metodo Select sceglie di restituirti un oggetto di tipo WhereSelectEnumerableIterator<System.Xml.Linq.XElement,string> che viene usato internamente per garantirti query componibili senza per questo pesare sulle prestazioni.
Comunque è una roba che riguarda il funzionamento interno di LINQ, non te ne curare. Per il principio di sostituzione di Liskov, tutto quello che ti serve sapere è che quel tipo di ritorno implementi IEnumerable<string>. Non ha importanza quale sia la sua logica interna.

Invece, se ti chiedi come mai oltre a string venga menzionato anche il parametro di tipo XElement, questo dipende dal funzionamento del metodo Select. Essendo un metodo di proiezione, ovvero che trasforma oggetti di un tipo in nuovi oggetti di un altro tipo (dall'XElement "ora" alla stringa "Start", in questo caso) ha bisogno di conoscere il tipo di oggetto che riceverà in input e quello che fornirà come risultato.

ciao

---

Modificato da BrightSoul il 28 giugno 2013 23.18 -

Se lavori con XML consiglio l'utilizzo di questo tool:

http://xsd2code.codeplex.com/