Need Help With Detecting Element Block "Exit"

[beachnut]

Hi, all.
This should be pretty easy:

When parsing my XmlDocument object with a validating
reader, what's the proper way to detect when it
"exits" an element's block? It's the first time
I've needed to toggle a bool when entering and
exiting one; I tried to trap the exit with
'case "</block>":', but that doesn't work.

FWIW, I have the XML representation of a table,
and some of its rows have a nested table. I want to
add a parent ID to each nested table. Maybe there's
a better way to do this?

Oh, I only need a small subset of the large XML doc,
so I'm not planning on deserializing it into a complex
object.

Thanks!
bn

[Derek Harmon]

"beachnut" <ho**********@hotmail.com> wrote in message news:bb**************************@posting.google.c om...

When parsing my XmlDocument object with a validating
reader, what's the proper way to detect when it
"exits" an element's block?
You probably have a loop that looks like,

while ( validatingReader1.Read( ) )
{
;
}

So what you can do is check the NodeType to see if
it's XmlNodeType.EndElement.

string atomBlock = validatingReader1.NameTable.Get( "block");
while ( validatingReader1.Read( ) )
{
if ( validatingReader1.NodeType == XmlNodeType.EndElement )
{
if ( validatingReader1.LocalName == atomBlock )
{
// Do something when the </block> end tag has been parsed.
}
}
}

Another approach is to subclass XmlValidatingReader and override the
Read( ) method (to call base.Read( ) and then check the NodeType and
LocalName to raise an event notification or something when it hits the end
tags it's interested in), then use an instance of your specialized XmlValidating-
Reader to load your XmlDocument.
and some of its rows have a nested table. I want to
add a parent ID to each nested table. Maybe there's
a better way to do this?

It's a relational question, not an XML question. In XML, the "nested table"
is contained by a parent element, therefore the notion of having a parent ID
is redundant. If you have an XmlNode in the nested table, you can move
to a node of the parent table using the ParentNode property.

Another issue to watch out for with having these parent IDs (as it is an issue
when dealing with any sort of data redundancy) is keeping them up-to-date
if you ever relocate a portion of the node tree elsewhere.

Sometimes data redundancy is a good thing (balancing data normalization
with locality of reference), but in this case when the parent nodes are there
for you I don't believe it's worthwhile. What do you want to do with an ID
to the parent ... using it to search the entire document isn't going to expedite
anything.
Derek Harmon