SMPTE   AG   05
Administrative Guideline

XML in Engineering Documents

Published Approved - 2023-04-09 2025-03-25

Copyright © 2025 , Society of Motion Picture and Television Engineers . All rights reserved. No part of this material may be reproduced, by any means whatsoever, without the prior written permission of the Society of Motion Picture and Television Engineers.

Table of contents 🔗

  1. Foreword
  2. 1 Scope
  3. 2 Conformance
  4. 3 Normative references
  5. 4 Terms and definitions
  6. 5 General
    1. 5.1 License
    2. 5.2 Header
  7. 6 XML Namespaces
    1. 6.1 Overview (informative)
    2. 6.2 XML Elements and Attributes
    3. 6.3 Defining XML Namespaces
    4. 6.4 SMPTE XML Namespaces
      1. 6.4.1 Name Syntax
      2. 6.4.2 Examples (informative)
      3. 6.4.3 Registration (informative)
    5. 6.5 Change Policy
    6. 6.6 XML Namespace Definition Document
    7. 6.7 Compatibility with Legacy XML Namespace URI Syntax
  8. 7 XML Schema
    1. 7.1 Introduction (informative)
    2. 7.2 Using XML Schema
    3. 7.3 Precedence
    4. 7.4 Avoiding Discrepancies
    5. 7.5 Language Version
    6. 7.6 External Definitions
    7. 7.7 Well-Formed Definitions
    8. 7.8 Example Instances
    9. 7.9 Publication
  9. Annex A XML Document License
  10. Annex B XML Element Header
  11. Annex C Sample XML Namespace Definition Document (informative)
  12. Bibliography

Foreword 🔗

SMPTE (the The Society of Motion Picture and Television Engineers) Engineers (SMPTE) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTE’s Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual. For more information, please visit www.smpte.org .

This Standards Administrative Guideline forms an adjunct to the use and interpretation of the SMPTE Standards Operations Manual. In the event of a conflict, the Operations Manual shall prevail.

Copyright © The Society of Motion Picture and Television Engineers.

1 Scope 🔗

This Administrative Guideline specifies selected uses of the Extensible Markup Language (XML) in SMPTE Engineering Documents.

2 Conformance 🔗

Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords. All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as "Informative" or individual paragraphs that start with "Note:" The following keywords "shall" and "shall not" indicate requirements strictly to be followed have a specific meaning in order to conform to the document context of this document:

3 Normative references 🔗

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

4 Terms and definitions 🔗

No terms and definitions are listed in this document.

5 General 🔗

5.1 License 🔗

Any document that (a) is defined by an Engineering Document and (b) conforms to Extensible Markup Language (XML) 1.0 (Fifth Edition) , whether within the prose or as an Additional Element, shall be licensed according to Clause Annex A .

5.2 Header 🔗

Additional Elements of Engineering Documents that conform to Extensible Markup Language (XML) 1.0 (Fifth Edition) should include the text of Clause Annex B , at the head of document and with the text between triple brackets replaced as specified.

6 XML Namespaces 🔗

6.1 Overview (informative) 🔗

XML namespaces, specified in Namespaces in XML 1.0 (Third Edition) , are used to avoid collisions between independent XML vocabularies (attributes and elements), and provide an unambiguous and human-readable link to the specifications that define these vocabularies. Each XML namespace has its unique name, which is a URI that conforms to IETF RFC 3986 .

6.2 XML Elements and Attributes 🔗

Each XML element and attribute defined by an Engineering Document should be qualified by an XML namespace name, as defined in Namespaces in XML 1.0 (Third Edition) .

NOTE — —⁠ It is customary for related elements and attributes to share a common XML namespace.

6.3 Defining XML Namespaces 🔗

In most circumstances, an Engineering Document that defines XML elements and attributes will also define one or more XML namespaces, since it is rarely possible to add items to an XML namespace defined elsewhere. An Engineering document may define any number of XML namespaces, and all such XML namespaces shall be SMPTE XML namespaces as specified in 6.4 , unless otherwise permitted by 6.7 .

6.4 SMPTE XML Namespaces 🔗

6.4.1 Name Syntax 🔗

The name of a SMPTE XML Namespace shall conform to the NS syntax below specified using IETF RFC 7405 :

" PUBNUM "/" REVISION [SHORTNAME] 
NS = %s"http://www.smpte-ra.org/ns/" PUBNUM "/" REVISION [SHORTNAME]
SHORTNAME = 1*4("/" 1*(ALPHA / DIGIT / "-" / "_" / ".") )
PUBNUM = 1*(DIGIT) ["-" 1*(DIGIT)]
REVISION = STABLEREV / EXPREV
STABLEREV = 4(DIGIT) [2(DIGIT)]
EXPREV = %s"experimental-" 1*(ALPHA / DIGIT / "-" / "_" / ".")
PUBNUM
shall represent the official publication number of the Engineering Document, without leading zeroes and including a part number, if any, separated by a hyphen, e.g. 456-1 .
SHORTNAME
is used when the Engineering Document defines more than one XML namespace. It may provide a human meaningful designation of the namespace, but shall not to include any version information.

The fragment identifier component shall not be present.

NOTE 1 — —⁠ While fragment identifier components are not used in namespace URIs, they can be used to generate identifiers unique to the specification, e.g. as values in enumerations.

A stable SMPTE XML namespace is a SMPTE XML namespace whose name is such that REVISION :

  • conforms to STABLEREV , which consists of a year encoded as 4 decimal digits and, optionally, a month encoded as 2 decimal digits in the range 1-12; and
  • represent the date that the XML namespace URI first appeared in the Engineering Document.

NOTE 2 — —⁠ The REVISON component of a stable SMPTE XML namespace does not necessarily correspond to the publication date of its defining Engineering Document. For instance, the defining Engineering Document can be revised in such a way that the contents of the XML Namespace remain unchanged. The XML Namespace Definition Document, specified in 6.6 , contains an unambiguous link to the published Engineering Document.

An experimental SMPTE XML namespace is a SMPTE XML namespace whose name is such that REVISION conforms to EXPREV .

Such experimental SMPTE XML namespace are available for use in draft Engineering Documents to readily identify XML namespaces that are hence susceptible to change prior to publication.

Until an Engineering Document is presented to Draft Publication ballot, any SMPTE XML namespace defined therein may be an experimental SMPTE XML namespace, unless the SMPTE XML namespace was previously defined in a published Engineering Document; thereafter, any SMPTE XML namespace defined in the Engineering document shall be a stable SMPTE XML namespace.

NOTE 3 — —⁠ No changes to XML namespace names are necessary following a Draft Publication ballot since XML namespace names are constructed independently of the publication date of the Engineering Document.

6.4.2 Examples (informative) 🔗

The following is an example name from a SMPTE XML namespace: 

http://www.smpte-ra.org/ns/456/2005/foo

One can immediately see that the namespace "foo" is defined in a SMPTE Engineering Document numbered "456" and initially appeared in the year "2005". One would assume that a "foo" was a well-known artifact to SMPTE members, at least for those that have read Engineering Document number "456".

The following is an example XML namespace name defined in a document with a part designation and that originally appeared in September of 2005: 

http://www.smpte-ra.org/ns/456-1/200509/foo

The following is a name from an XML namespace defined in a draft version of the same specification: 

http://www.smpte-ra.org/ns/456-1/experimental-20141001/foo

The following is not equivalent to the previous name since it is missing the string www. (the two URIs can nevertheless resolve to the same resource when used in an HTTP GET query): 

http://smpte-ra.org/ns/456-1/experimental-20141001/foo

The following is not a valid SMPTE XML Namespace since a fragment is used: 

http://www.smpte-ra.org/ns/456-1/experimental-20141001/foo#hello

6.4.3 Registration (informative) 🔗

The SMPTE XML namespace syntax ensures uniqueness across Engineering Documents, and thus no specific registration steps are required.

6.5 Change Policy 🔗

An Engineering Document that defines an XML namespace should specify whether the XML namespace is mutable, i.e. whether changes to the set of names defined by that XML namespace are allowed without also changing the name of the XML namespace.

6.6 XML Namespace Definition Document 🔗

For each XML namespace defined in an Engineering Document, an XML Namespace Definition Document shall be publicly retrievable at the XML Namespace URI.

Each XML Namespace Definition Document shall be human-readable and include:

The XML Namespace Definition Document should conform to HTML, as specified in HTML 5.2 .

Clause Annex C lists a sample XML Namespace Definition Document.

6.7 Compatibility with Legacy XML Namespace URI Syntax 🔗

Earlier versions of this Administrative Guideline specified a substantially different syntax for XML Namespace URIs. For instance, the string "schemas" was used instead of "ns" and a number sign ("#") character could terminate the URI, with an otherwise empty fragment identifier component. This syntax is deprecated.

Published Engineering Documents that conform to prior versions of this specification, as well as their revisions and amendments, may continue to do so.

7 XML Schema 🔗

7.1 Introduction (informative) 🔗

Using a formal language like XML Schema, specified in XML Schema Part 1: Structures Second Edition , to describe conformance requirements can avoid some of the ambiguity inherent with using English prose alone, while allowing the use of existing commercial tools to facilitate testing and validation.

NOTE — —⁠ The following provisions are derived in part from Good Practice 11 at HTML Living Standard and Guidelines for the Use of Formal Languages in IETF Specifications .

7.2 Using XML Schema 🔗

XML Schema, as specified in XML Schema Part 1: Structures Second Edition , may be used normatively or informatively in an Engineering Document, either by inclusion or by reference.

7.3 Precedence 🔗

Engineering Documents may specify a policy in case of a conflict between prose and XML Schema. In absence of such policy, the precedence rules specified in the Conformance section of SMPTE AG-04-ST , a Standard (ST), or SMPTE AG-04-EG Engineering Guideline (EG) respectively, applies. See SMPTE AG-27 for specific wording.

7.4 Avoiding Discrepancies 🔗

To help avoid discrepancies between the English prose and the XML Schema, prose sections should be bound to the related portion of the XML Schema, so that one cannot be modified without the other.

NOTE 1 — —⁠ One method to bind prose to XML Schema is to include XML Schema definitions inline within the prose. Another method is for the prose to refer to XML Schema definitions specified in appendices or Additional Elements.

Any Additional Element that conforms to XML Schema, and duplicates normative XML Schema definitions specified in the Prose Element, shall be normative.

NOTE 2 — —⁠ Informative XML Schema definitions can be used as examples, e.g. to demonstrate how to define an extension to another XML Schemas through the <xs:any> mechanism.

7.5 Language Version 🔗

Whenever an XML Schema is provided and any portion of it is normative, the Engineering Document shall provide a normative reference to the XML Schema specification it conforms to.

It is also recommended that a reference (although it may be bibliographic) be made to the XML language specification itself.

7.6 External Definitions 🔗

The defining document of any externally-defined XML namespaces shall be included as a normative reference if the XML schema is normative.

7.7 Well-Formed Definitions 🔗

All XML Schema defined in a SMPTE Engineering Document shall be well-formed and valid with respect to the XML Schema language.

7.8 Example Instances 🔗

All example instance documents shall be informative.

All example instance documents shall be well-formed. If an example instance document is document, then it shall be valid with respect to the XML Schema defined.

Graphical representations of the schema structure should be included when it adds clarity.

7.9 Publication 🔗

All Additional Elements of Engineering Documents conforming to XML Schema shall be publically retrievable at an HTTP URI chosen by the Director of Engineering.

NOTE — —⁠ The same URI is also listed in the Namespace Definition Document per 6.6 if the XML Schema Document specifies a target namespace.

Annex A
XML Document License 🔗 

Copyright (c), Society of Motion Pictures and Television Engineers. All rights
reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Annex B
XML Element Header 🔗 

<!--
[[TEXT OF XML DOCUMENT LICENSE OF  IN AG-05]]

[[TEXT OF XML DOCUMENT LICENSE IN AG-05 ABOVE]]

-->
<!--
This document can be retrieved at
 [[[INSERT URI WHERE THE DOCUMENT IS PUBLISHED]]]
  
and is an element of
 [[[INSERT SMPTE DOCUMENT REFERENCE]]] ,
which is available at http://standards.smpte.org.
To ensure interoperability, users are encouraged to:
(a) retain this notice;
(b) retrieve the recent versions of this document and its companion
defining engineering document. In particular, this document alone might
not be sufficient to ensure interoperability;
(c) highlight and explain any modification they make to this document; and
(d) report issues to [[[INSERT SMPTE CONTACT]]].
-->

Annex C
Sample XML Namespace Definition Document (informative) 🔗 

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>XML Namespace Definition Document for ST 2071-2</title>
</head>
<body>
<div>
 <p>This namespace is specified in
 SMPTE ST 2071-2:2016</p>
 <p>
 st2071-2q-2016.xsd is an XML Schema document associated with the namespace.</p>
 <p>
 < st2071-2r-2016.wsdl is a WSDL document associated with the namespace.</p>
</div>
</body>
</html>

Bibliography 🔗