XML parsing: no EndElement for combined start/end tags

[Zytan]

I thought each XmlNodeType.Element has a matching
XmlNodeType.EndElement. But, this does not occur when the XML file
has the following:

<example attr1="1" attr2="2" />

Even though this is syntactically the same as the following, which
does show the EndElement:

<example attr1="1" attr2="2">
</example>

You may be thinking, "duh, that's what the file shows", but in IE,
both cases are rendered as the single following line. They really are
supposed to be exactly the same. Is the XML reader broken?

Zytan

[Nicholas Paldino [.NET/C# MVP]]

Zytan,

Have you checked the files themselves in say, notepad? IE applys a
transformation on any XML that doesn't already have one applied to it to
produce the interactive HTML view that you see (with the collapsing
elements, etc, etc).

Your XML files should be coming out correctly. If not, can you show the
code that you are using to generate them?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Zytan" <zy**********@gmail.comwrote in message
news:11**********************@l77g2000hsb.googlegr oups.com...

>I thought each XmlNodeType.Element has a matching
XmlNodeType.EndElement. But, this does not occur when the XML file
has the following:

<example attr1="1" attr2="2" />

Even though this is syntactically the same as the following, which
does show the EndElement:

<example attr1="1" attr2="2">
</example>

You may be thinking, "duh, that's what the file shows", but in IE,
both cases are rendered as the single following line. They really are
supposed to be exactly the same. Is the XML reader broken?

Zytan

[Zytan]

Have you checked the files themselves in say, notepad?

Yes. This is how I confirmed that what I mention in the above post is
happening. Those are the results of what notepage shows, the actual
text file itself.

IE applys a
transformation on any XML that doesn't already have one applied to it to
produce the interactive HTML view that you see (with the collapsing
elements, etc, etc).

Yes, and this is where I noticed that IE decides that the two-line
case is identical to the one-line case, which the XML standard
indicates is true, also. Thus, an XML parser should correctly show
that BOTH start tag and end tag exists, regardless of the underlying
text-coding.

Your XML files should be coming out correctly. If not, can you show the
code that you are using to generate them?

I am not creating the XML files, but I have shown the code above as a
small example to show to exactly what the XML files are like. The
problem is not in the creation, and wondering why IE makes them look
different. IE 'standardizes' them in that it shows what the file
logically stands for, regardless of the underlying text-code, to make
it easy to read (good job, IE). The problem is that why does IE parse
them correctly, according to the standard, but the .NET framework does
not? So much is based on XML files that I am astounded that this
issue has not been raised. I have start tag + end tags in one line of
text code, and .NET is telling me no end tag (EndElement) exists!

Zytan

[Nicholas Paldino [.NET/C# MVP]]

Zytan,

You are going to have to provide a piece of code to show what you are
saying. Personally, I don't see it as an issue, as the infoset has no
concept of what an end tag is. That's something that is up to how you
represent the infoset (and the infoset does not have to be represented as a
text file, as WCF proves).

If you could provide the files that you are reading, and the code you
are using to read them, it would help greatly.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Zytan" <zy**********@gmail.comwrote in message
news:11*********************@o5g2000hsb.googlegrou ps.com...

> Have you checked the files themselves in say, notepad?

Yes. This is how I confirmed that what I mention in the above post is
happening. Those are the results of what notepage shows, the actual
text file itself.

>IE applys a
transformation on any XML that doesn't already have one applied to it to
produce the interactive HTML view that you see (with the collapsing
elements, etc, etc).

Yes, and this is where I noticed that IE decides that the two-line
case is identical to the one-line case, which the XML standard
indicates is true, also. Thus, an XML parser should correctly show
that BOTH start tag and end tag exists, regardless of the underlying
text-coding.

> Your XML files should be coming out correctly. If not, can you show
the
code that you are using to generate them?

I am not creating the XML files, but I have shown the code above as a
small example to show to exactly what the XML files are like. The
problem is not in the creation, and wondering why IE makes them look
different. IE 'standardizes' them in that it shows what the file
logically stands for, regardless of the underlying text-code, to make
it easy to read (good job, IE). The problem is that why does IE parse
them correctly, according to the standard, but the .NET framework does
not? So much is based on XML files that I am astounded that this
issue has not been raised. I have start tag + end tags in one line of
text code, and .NET is telling me no end tag (EndElement) exists!

Zytan

[Jon Skeet [C# MVP]]

Zytan <zy**********@gmail.comwrote:

I thought each XmlNodeType.Element has a matching
XmlNodeType.EndElement. But, this does not occur when the XML file
has the following:

<example attr1="1" attr2="2" />

No. You only have a start element node, but the element is empty. You
should use XmlReader.IsEmptyElement to check this condition.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Zytan]

I thought each XmlNodeType.Element has a matching

XmlNodeType.EndElement. But, this does not occur when the XML file
has the following:

<example attr1="1" attr2="2" />

No. You only have a start element node, but the element is empty. You
should use XmlReader.IsEmptyElement to check this condition.

Oh, so this is start tag without an end tag, and is normal. That
means the name 'start tag' is extremely misleading. It also means
that IE's reformatting of the XML file to show it more clearly (which
I like), is, in fact, wrong, since it's removing end tags (for
elements that have nothing in them, which are, I guess, empty
elements). Aalthough, I guess, no one really cares.

But, this answers my concern. It was no big deal, anyway, since for
all my empty elements, I wasn't expecting to get anything before I run
into the end tag, anyway, so the fact that it just never comes is not
really an issue.

Zytan

[Zytan]

Zytan,

>
You are going to have to provide a piece of code to show what you are
saying. Personally, I don't see it as an issue, as the infoset has no
concept of what an end tag is. That's something that is up to how you
represent the infoset (and the infoset does not have to be represented as a
text file, as WCF proves).

If you could provide the files that you are reading, and the code you
are using to read them, it would help greatly.

Sorry, Nicholas, I think you were just missing the what I was trying
to explain, and yeah, code would clear up that explanation, but Jon
has answered my question, please see his post, and you'll know just
what I was talking about, and what was bothering me. C#'s XML parsing
was working exactly as it should. It was the idea that an empty
element only has a start tag, and no end tag (who would have thought?
doesn't every start have an end?), that was bothering me.

Thanks for your replies,

Zytan

[Marc Gravell]

This bit me the first time I used XmlReader, too. I also made the
assumption that <node></nodeand <node/would behave the same in
terms of start/end tags (although perhaps the latter would be flagged
as empty at the same time to mark the subtle difference). Of course,
sample data soon burned me. I guess I'm just saying that you aren't
alone in getting a little misled by this, but the fix is fortunately
very easy (as per Jon's post).

Marc

[Zytan]

This bit me the first time I used XmlReader, too. I also made the

assumption that <node></nodeand <node/would behave the same in
terms of start/end tags (although perhaps the latter would be flagged
as empty at the same time to mark the subtle difference). Of course,
sample data soon burned me. I guess I'm just saying that you aren't
alone in getting a little misled by this, but the fix is fortunately
very easy (as per Jon's post).

Marc

Thank you for your story, Marc. I think the confusion is the
terminology. Since when does a 'start' not have an 'end'? Also, IE
confuses the issue since it removes end tags from empty elements that
are made from a start tag and an end tag with nothing inbetween, when
it displays XML, so that led me to believe that they were the same, as
well.

Zytan