9

We have some kind of problem with a customer which is arguing that there is a semantical difference between two versions of empty tag in an XML file we're sending (pure XML no HTML..).

They expect:

 <our-xml>
    <some-tag></some-tag>
 </our-xml>

We send:

 <our-xml>
    <some-tag />
 </our-xml>

We are of the opinion that this is exactly the same but we could not really prove the arguments with facts. Only thing we found was in https://www.w3.org/TR/REC-xml/#sec-starttags where it says

empty-element tags may be used for any element which has no content.

Is there any discussion or more clear paper that we can rely on or are we wrong?

kjhughes
  • 106,133
  • 27
  • 181
  • 240
Marcel
  • 4,054
  • 5
  • 36
  • 50

1 Answers1

12

No

Start-tag/End-tag (<tag></tag>) and Empty-element tag (<tag/>) forms are semantically equivalent. No conforming XML parser will treat them differently.

Reference: Extensible Markup Language (XML) 1.0 (Fifth Edition)

Historical note: There is also an antiquated SGML compatibility reference, which I include for completeness:

For interoperability, the empty-element tag should be used, and should only be used, for elements which are declared EMPTY.

  • 1.2 Terminology

    for interoperability

    [Definition: Marks a sentence describing a non-binding recommendation included to increase the chances that XML documents can be processed by the existing installed base of SGML processors which predate the WebSGML Adaptations Annex to ISO 8879.]

Related Q/A:

kjhughes
  • 106,133
  • 27
  • 181
  • 240
  • 1
    thank you! I'm literally astounded that you don't have "a million" upvotes for this answer ...possibly an illustration of how few people actually scrutinise the toolsets they use?? – Pancho Mar 25 '20 at 14:03
  • 1
    Do note that if you're writing/using a low-level parser or something what walks the XML structure, you may see a difference (a StartTag token followed by an EndTag token vs. just a Self-Closing Tag token - specifics depend on the parser you're using, and some parsers might not actually give a different parsing tree). But yeah, both are perfectly valid and need to be handled by the parser - it's a syntactic, not a semantic difference. – Michael Stum Jun 22 '21 at 15:14