A couple of dumb c# / xml questions

  • Thread starter Thread starter tomldn
  • Start date Start date
T

tomldn

Hi, sorry if these questions are basic... I'm learning to use xml with
c# and am lacking experience.

1) Obviously XPathNavigator and XMLDocument work together. What
situations would someone use XMLTextReader? Wouldn't you always want
to navigate a document using XPath?

2) When I'm designing XML and I want to add a "value" to an element.
Are there any pros and cons to using attributes vs child elements? Are
there any times it's best to use each?

Cheers for any help, Tom.
 
1) Obviously XPathNavigator and XMLDocument work together. What
situations would someone use XMLTextReader? Wouldn't you always want
to navigate a document using XPath?
Click to expand...

If you were to read a 10 GB XML file you would fine out the
advantage of XmlTextReader.

(it does not read the entire document into memory)
2) When I'm designing XML and I want to add a "value" to an element.
Are there any pros and cons to using attributes vs child elements? Are
there any times it's best to use each?
Click to expand...

Do you prefer VW or Toyota ?

:-)

This is frequently discussed among XML users.

I agree mostly with the view in:
http://www.ibm.com/developerworks/xml/library/x-eleatt.html

Arne
 
If you were to read a 10 GB XML file you would fine out the
advantage of XmlTextReader.

(it does not read the entire document into memory)


Do you prefer VW or Toyota ?

:-)

This is frequently discussed among XML users.

I agree mostly with the view in:
   http://www.ibm.com/developerworks/xml/library/x-eleatt.html

Arne
Click to expand...

Hi Arne,

Thanks for your help on this and thanks for the link - I'll read it
thoroughly today.

Any chance of a couple of quick questions regarding the 10 gig XML
file - how would you search this please? Is XPath not an option for
large files? Would you have to read through the nodes using
XMLTextReader and just record where you are and extract any values you
wanted?

Cheers, Tom.
 
Any chance of a couple of quick questions regarding the 10 gig XML
file - how would you search this please? Is XPath not an option for
large files? Would you have to read through the nodes using
XMLTextReader and just record where you are and extract any values you
wanted?
Click to expand...

Either that or buy a very powerful PC.

:-)

If you are so lucky that the info you are looking for
is in the top of the file, then it is double efficient - not
only do you not need to have everything in memory - you
can also stop parsing as soon you have what you are
looking for.

Arne
 
Hi Arne,

Thanks for your help on this and thanks for the link - I'll read it
thoroughly today.

Any chance of a couple of quick questions regarding the 10 gig XML
file - how would you search this please? Is XPath not an option for
large files? Would you have to read through the nodes using
XMLTextReader and just record where you are and extract any values you
wanted?
Click to expand...

Using XPath would require you to load the entire document into memory.
10Gb might be a problem.

With XmlReader (note that XmlTextReader is actually deprecated - you
should use XmlReader.Create), in certain specific cases, you can just
do a linear scan of the file. Consider an XML that is really just a
collection of records:

<people>
<person>
<first-name>John</first-name>
<last-name>Doe</last-name>
...
</person>
...
</people>

This is pretty typical of a dataset dumped to XML. Now if you want to
find a person by first name, you really don't need the whole thing in
memory - you can just read it record by record, comparing name for
each. You don't need to have more than one loaded at a time to do
that.

In practice though, unless you're really dealing with multi-megabyte
XML files, there's nothing wrong with using XPath (it will typically
be much shorter than using XmlReader and manual scan). Even better is
to use LINQ to XML, as, unlike XPath, your predicate will be in C#,
and will be checked for syntactical correctness at compile time (that
said, there are some cases where XPathDocument beats XDocument in
terms of performance - specifically, on lookups using reverse document
order axes such as preceding:: and preceding-sibling::)
 
Back
Top