SMPTE
AG
05
Administrative
Guideline
SMPTE (the Society of Motion Picture and Television Engineers) 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.
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.
This Administrative Guideline specifies selected uses of the Extensible Markup Language (XML) in SMPTE Engineering Documents.
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 keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.
The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.
The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.
The keyword "reserved" indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword "forbidden" indicates "reserved" and in addition indicates that the provision will never be defined in the future.
Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; Tables shall be next; then formal languages; then figures; and then any other language forms.
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.
No terms and definitions are listed in this document.
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 .
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.
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 .
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.
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 .
The name of a SMPTE XML Namespace shall conform to the NS syntax below specified using IETF RFC 7405 :
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 / "-" / "_" / ".")
456-1
.
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
:
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
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.
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
The SMPTE XML namespace syntax ensures uniqueness across Engineering Documents, and thus no specific registration steps are required.
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.
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.
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.
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 .
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.
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 , or SMPTE AG-04-EG respectively, applies.
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.
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.
The defining document of any externally-defined XML namespaces shall be included as a normative reference if the XML schema is normative.
All XML Schema defined in a SMPTE Engineering Document shall be well-formed and valid with respect to the XML Schema language.
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.
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.
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.
<!-- [[TEXT OF XML DOCUMENT LICENSE OF Clause Annex A IN AG-05]] --> <!-- 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]]]. -->
<!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>