How do I detect empty tags?

[vega]

How do I detect empty tags if I have the DOM document?

For example: <br /> and <br></br>

I tried org.w3c.dom.Node.getFirstChild(), it returns null for both <br
/> and <br></br>
I also tried getNodeValue(), they both returns null also.

I know <br /> and <br></br> are the same from the xml spec. Is there
any way to tell the different syntax using DOM parser?

Thanks,
-John

 

[Andy Dingley]

How do I detect empty tags if I have the DOM document?

For example: <br /> and <br></br>

You can't and you don't need to. In XML these are exactly
equivalent(sic).

http://www.w3.org/TR/2004/REC-xml-20040204/#sec-starttags

"Empty-element tags MAY be used for any element which has no content,
whether or not it is declared using the keyword EMPTY. For
interoperability, the empty-element tag SHOULD be used, and SHOULD
only be used, for elements which are declared EMPTY."


There may be a useful difference you can find in the element's
definition from DTD or schema - i..e. EMPTY You can access this by
either parsing it, or (more easily) by using a document parser that
understands schema and offers a more direct link to the relevant one.

This is the definition though, not the instance. It won't tell you if
the empty-element form of the tag in your document was used because
it's an EMPTY element, or just a non-empty element that happens to
have no content in this instance.


In general though, the way the document was serialised is not visible
to an XML application and even more importantly there is NO reason why
it needs to be. You just never need it.

If you do think you need it, then the chances are that you're in a
non-XML context, such as XHTML or RSS. Although these are ostensibly
XML protocols, they exist in an environment that's still rooted in the
HTML past. There may be valid reasons for still caring about things
that a purely XML context wouldn't need to.

 

[Mukul Gandhi]

<br/> and <br></br> are same according to XML spec.. I do not think
any compliant XML parser would treat these two ways differently. So I
think the XML parser cannot report this difference..

Just also curious, for what purpose this information is useful to
you..

Regards,
Mukul

 

[Richard Tobin]

<br/> and <br></br> are same according to XML spec.. I do not think
any compliant XML parser would treat these two ways differently. So I
think the XML parser cannot report this difference..

An XML parser can report what it likes, but it would usually be unwise
to write software that depended on the difference. For one thing,
passing the document through any common XML program might well change
it.

The XML Infoset does not distinguish between the two forms.

Just also curious, for what purpose this information is useful to
you..

Editor-like applications should preserve the user's preferred
formatting, and ideally so should any application that doesn't
completely alter the structure of the document.

-- Richard

 

[Jon Haugsand]

* Richard Tobin

Editor-like applications should preserve the user's preferred
formatting, and ideally so should any application that doesn't
completely alter the structure of the document.

Would <br><!-- metainformation comment --></br> be illegal according
to the spec?

 

[Malte]

* Richard Tobin



Would <br><!-- metainformation comment --></br> be illegal according
to the spec?

Das interessiert mich auch. Ich habe hier nachgeschaut:

http://www.w3.org/TR/xhtml1/#C_2

Dort heisst es man sollte <br /> bevorzugen (statt <br></br>) (xhtml)

und hier

http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#edef-BR

Hier heisst es, dass <br /> nicht erlaubt sei (html 4.01) (Start tag:
required, End tag: forbidden)

 

[Andy Dingley]

Would <br><!-- metainformation comment --></br> be illegal according
to the spec?

Yes. (according to XML 1.0)
http://www.w3.org/TR/2004/REC-xml-20040204/#NT-content
"The representation of an empty element is either a start-tag
immediately followed by an end-tag, or an empty-element tag."

Note "immediately"

<br/> is equivalent to <br />
<br /> is equivalent to <br></br>

<br>[... anything ...]</br> is _not_ equivalent to <br></br>

Even <br> </br> (simple whitespace) is not empty content and thus is
invalid for an element defined as EMPTY


Of course in most cases this will be treated as valid, because <br />
is presumed to be an XHTML element and most XHTML gets handled by a
HTML parser, not an XML parser.

 

[David Carlisle]

Of course in most cases this will be treated as valid, because <br />
is presumed to be an XHTML element and most XHTML gets handled by a
HTML parser, not an XML parser.


Except that if it gets handled by a real HTML parser it is valid but
equivalent to <br>> so typesets a > at the start of the new line.

See what onsgmls makes of:

<html><head><title>a</title></head>
<body>
<br/><br>>
</body>
</html>


(BODY
AID IMPLIED
ACLASS IMPLIED
ASTYLE IMPLIED
ATITLE IMPLIED
ACLEAR TOKEN NONE
(BR
)BR
->
AID IMPLIED
ACLASS IMPLIED
ASTYLE IMPLIED
ATITLE IMPLIED
ACLEAR TOKEN NONE
(BR
)BR
->
)BODY
)HTML
C


David

 

[Andy Dingley]

Except that if it gets handled by a real HTML parser

But is HTML SGML ? I accept your point for SGML certainly, but
HTML is a world-of-hacks no matter how you look at it.

 

[Alan J. Flavell]

But is HTML SGML ?

The W3C say both yes and no. This has been discussed before, or
course: in the body of the HTML specification, they describe HTML as
an application of SGML, but then later on they rule-out certain
constructions when SGML didn't allow to be ruled out. That's the way
I understood the argument, anyway.

I accept your point for SGML certainly, but HTML is a world-of-hacks
no matter how you look at it.

Indeed. And XHTML/1,0 Appendix C continued that messy tradition.
Quite why so many newcomers aspire to just that, beats me.

 

[Richard Tobin]

Would <br><!-- metainformation comment --></br> be illegal according
to the spec?

Well-formed but invalid. An element declared EMPTY must have "no
content (not even entity references, comments, PIs or white space)".

-- Richard

 

[Peter Flynn]

Das interessiert mich auch. Ich habe hier nachgeschaut:

http://www.w3.org/TR/xhtml1/#C_2

Dort heisst es man sollte <br /> bevorzugen (statt <br></br>) (xhtml)

und hier

http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#edef-BR

Hier heisst es, dass <br /> nicht erlaubt sei (html 4.01) (Start tag:
required, End tag: forbidden)

That is SGML. The SGML form for EMPTY elements is <br> (no slash).

///Peter

 

[Peter Flynn]

You can't and you don't need to. In XML these are exactly
equivalent(sic).

It was a bone of contention at design time. Many contributors felt that
the Null End Tag trick was useful ONLY when the element was declared
EMPTY, and that the full form <foo></foo> meant something different (eg
"this is an element which CAN have content, it just doesn't happen to
have any on this occasion") and that to conflate them was poor design.
They lost.

///Peter

 

[Jan Roland Eriksson]

It was a bone of contention at design time. Many contributors felt that
the Null End Tag trick...

Not so fast; let's get this right in the first place and say that it's
about a NESTC+NET "trick" (if you really want to call it a trick?)

The original definition is here of course...

http://www.y12.doe.gov/sgml/wg8/document/1955.htm

....where the (informative) SGML declaration for XML has the following
DELIM definitions (among others)

NESTC "/" (NET-Enabling Start-Tag Close)
NET ">" (Null End-Tag)

...was useful ONLY when the element was declared EMPTY...

Actually it was the other way around, the "trick" was supposed to be
useful when you had _no_ declarations available at all, as in "DTD'less
parsing" of fully tagged, i.e. "well formed" instances of markup.

...and that the full form <foo></foo> meant something different (eg
"this is an element which CAN have content, it just doesn't happen to
have any on this occasion") and that to conflate them was poor design.

Exactly, and a useful distinction precisely for the cases where you need
to parse an instance without the inclusion of a declaration subset.

Had the distinction been kept, we would have been able to give the OP a
useful answer here in this thread, but as it all went haywire after some
very big companys rep's started to stick their nose too deep into the
issue, oh well...

They lost.

We have had lots of those over the years, sad to say.