NENA 01-002 · Web viewUsing “Page Layout” insert the ... This word, or the...

(Moderate proficiency in WORD is a prerequisite to authoring or “WORD-smithing” a new or revised NENA document.) All “red” explanatory text (except copyright text) IS TO BE REMOVED prior to submitting the document for approval. When typing the hyphen in 9-1-1, if you use cntrl+shift+hyphen the hyphen is treated as a letter and 9-1-1 will not be separated as it will with a hyphen.

Using “Page Layout” insert the watermark for DRAFT. Using “Page Layout”, “Line Numbers”, Select “Continuous”The note below the document title must remain in blue until the NENA Executive Board approves the document for publication. The CRM will populate all information on this page except the document title, which the Working Group will develop.

NENA [Template for Creating or Updating Committee

Standard Document]

This DRAFT document is not intended for distribution beyond the groups developing or reviewing the document. The document is also not intended to be used or referenced for development or procurement purposes until final publication. All draft material is subject to change and it is possible that the document itself may never be approved for publication.

NENA [Standard Document Name]

NENA-STA-XXX.X-YYYY (initial doc would be .1 - first revision would be .2, etc.) DSC Approval: MM/DD/YYYYPRC Approval: MM/DD/YYYYNENA Executive Board Approval: MM/DD/YYYYNext Scheduled Review Date: MM/DD/YYYY (See ADM-002 Section 7.3.1 for details. The review date will be recommended by the Authoring Committee and once approved the date will be identified on the cover page of the document. Minimum 1 yr / Maximum 3-5 yrs)

Prepared by:National Emergency Number Association (NENA) [insert the applicable Committee, Subcommittee and/or WG names as applicable]

Published by NENAPrinted in USA

123456789

101112

13

14

15

17181920212223

2627

28293031

323334353637

NENA [Document Name]NENA-STA-XXX.X-YYYY, Month Day, Year

NENASTANDARD DOCUMENT

NOTICE

This Standard Document (STA) is published by the National Emergency Number Association (NENA) as an information source for the designers, manufacturers, administrators and operators of systems to be utilized for the purpose of processing emergency calls. It is not intended to provide complete design or operation specifications or parameters or to assure the quality of performance for systems that process such equipment or services.

NENA reserves the right to revise this Standard Document for any reason including, but not limited to:

Conformity with criteria or standards promulgated by various agencies, Utilization of advances in the state of the technical arts, Or to reflect changes in the design of equipment, network interfaces or services described

herein.

This document is an information source for the voluntary use of communication centers. It is not intended to be a complete operational directive.

It is possible that certain advances in technology or changes in governmental regulations will precede these revisions. All NENA documents are subject to change as technology or other influencing factors change. Therefore, this NENA document should not be the only source of information used. NENA recommends that readers contact their 9-1-1 System Service Provider (9-1-1 SSP) representative to ensure compatibility with the 9-1-1 network, and their legal counsel to ensure compliance with current regulations.

Patents may cover the specifications, techniques, or network interface/system characteristics disclosed herein. No license expressed or implied is hereby granted. This document shall not be construed as a suggestion to any manufacturer to modify or change any of its products, nor does this document represent any commitment by NENA or any affiliate thereof to purchase any product whether or not it provides the described characteristics.

This document has been prepared solely for the use of 9-1-1 System Service Providers, network interface and system vendors, participating telephone companies, 9-1-1 Authorities, etc.

By using this document, the user agrees that NENA will have no liability for any consequential, incidental, special, or punitive damages arising from use of the document.

NENA’s Committees have developed this document. Recommendations for change to this document may be submitted to:

National Emergency Number Association1700 Diagonal Rd, Suite 500Alexandria, VA 22314202.466.4911or [email protected]

© Copyright YYYY National Emergency Number Association, Inc.

[MM/DD/YYYY] of 16

12

3383940414243444546

4748

49505152

5354

555657585960

6162636465

6667

6869

7071

727374757677

mailto:[email protected]


ACKNOWLEDGEMENTS

The National Emergency Number Association (NENA) [XXX Committee, Subcommittee and/or WG names] developed this document. Replace the words “XXX Committee, Subcommittee and/or WG names” with wording appropriate to your particular document’s creators (i.e. Core Services, Data Structures Subcommittee, XML WG).

NENA recognizes the following industry experts and their employers for their contributions in development of this document.

Executive Board Approval Date [MM/DD/YYYY]

The table below shall contain the names of persons who have actively contributed (verbally or in writing) to the development of the document. The employer name shall be the name of the person’s employer at the time the document is approved by the NENA Executive Board.

Members EmployerCommittee Co-Chair Name, XXX Committee Co-Chair

Member employer

Committee Co-Chair Name, XXX Committee Co-Chair

Member employer

WG Leader Name, Working Group Co-Chair

Member employer

WG Member Name, Technical Editor [if different than WG Leader]

Member employer

WG Member Name Member employerWG Member Name Member employerWG Member Name Member employerWG Member Name Member employerWG Member Name Member employerWG Member Name Member employer

Special Acknowledgements:

Delaine Arnold ENP, Committee Resource Manager, has facilitated the production of this document through the prescribed approval process.

[Additional names and description of reasons for acknowledgement]

The Working Group Name Working Group is part of the NENA Development Group that is led by: Pete Eggimann ENP and Jim Shepard ENP, Development Steering Council Co-Chairs Roger Hixson ENP, Technical Issues Director Chris Carver ENP, PSAP Operations Director

[MM/DD/YYYY] of 16

45

678

79

80818283

8485

86

87

888990

9192

9394

95

96979899

100101


Table of Contents

1 EXECUTIVE OVERVIEW................................................................................................................................5

2 INTRODUCTION...............................................................................................................................................5

2.1 OPERATIONS IMPACTS SUMMARY..........................................................................................................................52.2 TECHNICAL IMPACTS SUMMARY............................................................................................................................52.3 SECURITY IMPACTS SUMMARY..............................................................................................................................52.4 DOCUMENT TERMINOLOGY....................................................................................................................................52.5 REASON FOR ISSUE/REISSUE..................................................................................................................................62.6 RECOMMENDATION FOR ADDITIONAL DEVELOPMENT WORK...............................................................................62.7 ANTICIPATED TIMELINE.........................................................................................................................................62.8 COST FACTORS.......................................................................................................................................................72.9 COST RECOVERY CONSIDERATIONS.......................................................................................................................72.10 ADDITIONAL IMPACTS (NON-COST RELATED)....................................................................................................72.11 INTELLECTUAL PROPERTY RIGHTS (IPR) POLICY.............................................................................................82.12 ABBREVIATIONS, TERMS AND DEFINITIONS......................................................................................................8

3 HEADING DESCRIPTION (REPLACE WITH AN APPROPRIATE TITLE).........................................10

3.1..................................................................................................................................................................................103.1.1..........................................................................................................................................................................10

4 NENA REGISTRY SYSTEM (NRS) CONSIDERATIONS..........................................................................10

4.1 [REGISTRY NAME]................................................................................................................................................114.1.1 Registry Title/Name....................................................................................................................................114.1.2 Parent Registry...........................................................................................................................................114.1.3 Information required to create a new value...............................................................................................114.1.4 Management Policy....................................................................................................................................114.1.5 Content.......................................................................................................................................................124.1.6 Initial Values..............................................................................................................................................12

4.2 NEW VALUES FOR [REGISTRY NAME] THIS SECTION IS ONLY FOR ADDING VALUES TO AN EXISTING REGISTRY.12

5 DOCUMENTATION REQUIRED FOR THE DEVELOPMENT OF A NENA XML SCHEMA.............13

5.1 SCHEMA NAME....................................................................................................................................................135.2 SCHEMA PURPOSE................................................................................................................................................135.3 PARENT ELEMENT................................................................................................................................................135.4 CHILD ELEMENTS.................................................................................................................................................135.5 WSDL NEEDED....................................................................................................................................................145.6 XML EXAMPLE(S)...............................................................................................................................................145.7 ADDITIONAL NOTES.............................................................................................................................................14

6 RECOMMENDED READING AND REFERENCES...................................................................................14

7 PREVIOUS ACKNOWLEDGMENTS...........................................................................................................14

EXHIBIT A: EXAMPLE OF SECTION 5..............................................................................................................15

[MM/DD/YYYY] of 16

78

9102

103

104

105

106107108109110111112113114115116117

118

119120

121

122123124125126127128129

130

131132133134135136137

138

139

140

141


1 Executive Overview[This section should provide a summarized description of the document to include the purpose and scope of this document, the reason to implement the subject matter, and an explanation of the benefits. In most cases this section should not be more than one (1) page.]

2 Introduction

2.1 Operations Impacts Summary[This section is to contain verbiage applicable to the impacts this NENA Standard Document will/may have on Operational aspects of the 9-1-1 industry, particularly at the PSAP. For examples of content for this section, recently published documents may be reviewed.]

2.2 Technical Impacts Summary[This section is to contain verbiage applicable to the impacts this NENA Standard Document will/may have on technical aspects of the 9-1-1 industry, particularly with the 9-1-1 network (including data) and/or CPE equipment. For examples of content for this section, recently published documents may be reviewed.]

2.3 Security Impacts Summary[This section is to contain verbiage applicable to the impacts this NENA Standard Document will/may have on Security aspects of the 9-1-1 industry, particularly within the context of Next-Generation 9-1-1. Examples of Security Impacts might include threats and risks associated with the availability, privacy and security of the infrastructure, facilities and personnel affected by the proposed standard or recommendation. For examples of content for this section, recently published documents may be reviewed.]

It is strongly encouraged that the Working Group Leader consult with the current NENA Working Group/Committee charged with oversight of security related topics or to the DSC Co-Chairs. Additionally, the “Technical/Operational Description section” of this document may contain more detailed security comments, including technical or operational security details.]

2.4 Document Terminology The terms "SHALL", "MUST", "MANDATORY", and "REQUIRED" are used throughout this document (emphasized by using UPPER CASE) to indicate normative requirements and to differentiate from those parameters that are recommendations. Recommendations are identified by the words "SHOULD", "MAY", "DESIRABLE" or "PREFERABLE," also by the chosen form of emphasis. Any of these words used in lower case and not emphasized do not have special significance beyond normal usage. This section defines key words as they should be interpreted in NENA documents. The form of emphasis (UPPER CASE) shall be consistent and exclusive throughout the document.

1. MUST: This word, or the terms "required" or "shall", mean that the definition is an absolute requirement of the specification.

[MM/DD/YYYY] of 16

1011

12

142

143144145

146

147

148149150

151

152153154155

156

157158159160161162

163164165166

167

168169170171172173174175

176177


2. MUST NOT: This phrase, or the phrase "shall not", mean that the definition is an absolute prohibition of the specification.

3. SHOULD: This word, or the adjective "recommended", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT: This phrase, or the phrase "not recommended" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

5. MAY: This word, or the adjective "optional", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option “must” be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option “must” be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

These definitions are based on IETF RFC 2119.

2.5 Reason for Issue/ReissueNENA reserves the right to modify this document. Upon revision, the reason(s) will be provided in the table below.

Document Number Approval Date Reason For ChangesNENA-STA-xxx.1-YYYY [MM/DD/YYYY] Initial DocumentNENA-STA-xxx.2-YYYY [MM/DD/YYYY] [Reason for revision]NENA-STA-xxx.3-YYYY [MM/DD/YYYY] [Reason for revision]

2.6 Recommendation for Additional Development Work[This section is to contain verbiage intended to provide wording appropriate to your particular document’s content. Provide a yes or no answer, plus supportive reasoning, to the question “is standards development work needed for this topic?”.]

2.7 Anticipated Timeline [This section is to contain verbiage intended to provide guidance regarding the anticipated length of time involved in achieving full deployment or implementation of the subject(s) covered by this NENA document. Explain what steps have to take place to achieve implementation within this anticipated timeline. If no anticipated timeline is known, this section should state that deployment or implementation will take place as required.]

[MM/DD/YYYY] of 16

1314

15178179

180181182

183184185186

187188189190191192193194

195

196

197198

199

200201202

203

204205206207208

https://datatracker.ietf.org/doc/rfc2119/


2.8 Cost Factors[This section is to contain verbiage intended to provide a brief summary of potential system or application cost impacts regarding the subject of this NENA document. If it is not applicable in any given document, simply enter “Not Applicable” in this section.]

NOTE to document editor: [As you think about this subsection, consider the following points];

Did the WG appropriately consider all known alternatives for achieving the stated goal(s)? Did the WG consider the proposed solution(s) shown in the DRAFT document for their

effectiveness in achieving the goal(s)? Did the WG evaluate the "ease of transition" for the stakeholders who would need to

implement whatever new steps the document might be advocating, i.e. will the expense of implementation be worth it, in light of other changes that might be taking place in parallel with publication of this new NENA document?

Did the WG evaluate the "ease of network evolution" for the stakeholders who would need to implement whatever new steps the document might be advocating, i.e. how well does it fit with other naturally occurring changes in overall network architecture?

2.9 Cost Recovery Considerations[This section is intended to provide information for cost recovery items other than normal business practices, if applicable (e.g.; grants, surcharge funds, etc.). If it is not applicable in any given document, simply enter “Not Applicable” in this section OR this section should state that normal business practices shall be assumed to be the cost recovery mechanism.]

2.10 Additional Impacts (non-cost related)[This section is to contain verbiage intended to provide a summary of potential system or application impacts regarding the subject of this NENA document. Generally one of the following four paragraphs will suffice as “starting text” for this section.]

NOTE to document editor: Replace the “Additional Impacts” section’s wording with wording appropriate to your particular document’s content by choosing one of these four, or provide appropriate wording if none of these four apply. Pick one of these four, and insert the words “9-1-1 technical” or “9-1-1 Center operations” as applicable in place of the “XXX”:

1. The information or requirements contained in this NENA document are not expected to have XXX impacts, based on the analysis of the authoring group.

2. The information or requirements contained in this NENA document are expected to have XXX impacts, based on the analysis of the authoring group. At the date of publication of this document, development had not started. The primary impacts are expected to include:

(Lists impacts as bullets, in a referenced appendix, if lengthy.)

[MM/DD/YYYY] of 16

1617

18209

210211212

213

214215216217218219220221222223

224

225226227228

229

230231232233234235236237238239240241242243244245246247248


3. The information or requirements contained in this NENA document are known to have XXX impacts, based on the analysis of the authoring group, and development has been started. The primary impacts include:

(List impacts as bullets, with the status of development, and in what group.)

4. Certain of the information or requirements contained in this NENA document are known to have XXX impacts, and others are not expected to have XXX impacts. At the date of publication of this document, some development work had begun.

(List impacts as bullets, with the status of development, and in what group.)

2.11 Intellectual Property Rights (IPR) PolicyNOTE – The user’s attention is called to the possibility that compliance with this standard may require use of an invention covered by patent rights. By publication of this standard, NENA takes no position with respect to the validity of any such claim(s) or of any patent rights in connection therewith. If a patent holder has filed a statement of willingness to grant a license under these rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license, then details may be obtained from NENA by contacting the Committee Resource Manager identified on NENA’s website at ww w .nena.org/i p r .

Consistent with the NENA IPR Policy, available at www.nena.org/ipr, NENA invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard.

Please address the information to:

National Emergency Number Association1700 Diagonal Rd, Suite 500Alexandria, VA 22314202.466.4911or [email protected]

2.12 Abbreviations, Terms and Definitions Please use this table to identify all new or updated 9-1-1 terms that are unique to NENA or the 9-1-1 system. All abbreviations used in this document are to be included in this table. Please add terms and abbreviations to the table using the following format:

Place term or abbreviation in the Term or Abbreviation (Expansion) column. For abbreviations, add the expansion (the spelled out words) in parenthesis; i.e., FCC (Federal Communications Commission).

Provide a brief description for the abbreviation or term. You may also cite an external reference for greater detail.

In the New (N) / Update (U) column, an entry is required for any new or updated term in this table. Any change made to a term, abbreviation, or definition already in the NENA Master

[MM/DD/YYYY] of 16

1920

21249250251252253254255256257258259

260

261262263264265266267268269270271272273274275276277278279

280

281282283

284285286287288289290

mailto:[email protected]

http://www.nena.org/ipr

http://www.nena.org/ipr


Glossary constitutes a proposed update. Terms, and abbreviations that are not updated have no entry in the New (N) / Update (U) column. The DSC will review proposed New and Updated terms for inclusion into the Master Glossary.

IMPORTANT: All Abbreviations and Terms must also be spelled out where they are first used within the document itself. This table shall contain all abbreviations used in this document, as well as any new (N) terms, or definitions that need to be updated (U) in the Master Glossary.

The entries in the table below in red font are examples only. Remove them once the editor understands how to format and use the table. Do not modify or remove the following paragraph, but do DELETE this red text and the red text in the table before publication.

See NENA-ADM-000, NENA Master Glossary of 9-1-1 Terminology, located on the NENA web site for a complete listing of terms used in NENA documents. All abbreviations used in this document are listed below, along with any new or updated terms and definitions.

Term or Abbreviation (Expansion)

Definition / Description New (N) / Update (U)

9-1-1 Service Area The geographic area that has been granted authority by a state or local governmental body to provide 9-1-1 service.[This row is an example of a Term that has no abbreviation.]

N

AE (Abbreviation Expansion)

The format that shows how to display abbreviations and their expansion in NENA documents.

N

ASD (Acute Stress Disorder)

ASD refers to clinically significant (causing significant distress or impairment in social, occupational, or other important areas of functioning) symptoms more than two days but less than one month after exposure to a trauma, as defined above (may progress to PTSD if symptoms last more than one month).

FCC (Federal Communications

Commission)

The FCC is an independent agency of the United States government, created and overseen by Congress to regulate interstate communications by radio, television, wire, satellite, and cable in all 50 states, the District of Columbia and U.S. territories. For details see http://www.fcc.gov/

U

i3 PSAP (i3 Public Safety Answering

Point)

A PSAP that is capable of receiving IP-based signaling for delivery of emergency calls and for originating calls and is conformant to NENA specifications for such PSAPs.

N

[MM/DD/YYYY] of 16

2223

24291292293

294

295296297298299300301302

303304305

306

http://www.fcc.gov/

https://www.nena.org/?page=Glossary


3 Heading Description (replace with an appropriate title)

3.1

3.1.1

3.1.1.1

NOTE to document editor: Your Document topic specific section/subsection Headings and descriptive text are to be included in this section.

[The Description serves as the beginning of the specific detailed portion of your document. The author(s) of your document would add any necessary headings within this section to complete your document. This section can be as long as needed for the document topic. In addition:

The document editor should be consistent with the use of bullets or item numbering. The document editor should clearly identify level 2-4 headings for sub-sections within the

“Description” section. The document editor should verify that drawings placed into the Working Group’s text are

formatted as a Windows enhanced metafile (.wmf).]

4 NENA Registry System (NRS) Considerations If this section is not applicable in any given document, simply enter “Not Applicable” in this section.

Whenever a standard has a list of items, especially where the list is used in an XML data structure, and the list is expected to change over time, the list should be maintained in a “Registry”. A registry is, at heart, just a table of data, with rows and columns. The Registry is established by a standard, which defines the columns and what they are used for. Each entry in the registry is a row, and has values for the columns specified. The standard that creates the registry usually defines the initial values (row and column content). It also specifies how a new value is added: we call that a “Management Policy”.

Registries can be hierarchical (Registry contains sub-registries, nested as needed) if you have a group of registries that are related.

Registries are maintained by the NENA Registry System (NRS), which operates according to NENA-STA-008.2 (formerly 70-001). The existing registries, with all of the content of the registry, are available in stable locations in the NENA website. Registries are stored as XML objects, although through custom style sheets, the registry content is human readable. The intent of storing the registries at stable URLs, in XML form, is that implementers of standards that use registries can automatically include current values in their implementations. NRS will only modify registries according to the management policy specified for that registry.

[MM/DD/YYYY] of 16

2526

27307

308

309

310

311

312313314315

316317318

319320321322323

324

325

326327328329330331332

333334

335336337338339340341

http://technet.nena.org/nrs/registry/_registries.xml


The section describes what the NRS should do: create a new registry, modify a registry design, add a new value to an existing registry, etc. Each distinct action should be in a separate subsection, although a group of related actions such as a set of new values for a single registry should be in a single section.

Write this section as a set of instructions to the people who operate the NRS. Tell them, in a clear and unambiguous way what, exactly, you want them to do. Don’t make assumptions. They may not read your document in its entirety, so this section has to stand alone. It can reference other parts of the document. For example, you may have a table in your document that has what you want the initial content of the registry to contain. That is okay, as long as the table specifies, exactly, what goes in each “cell” of the rows and columns.

This section defines [number] [registry or registries] to be [created or modified] in the NENA Registry System.

4.1 [Registry Name]Use this type of section to add a new registryNRS is requested to create a new registry, __________________. Describe what the registry is used for. Usually has a reference to the part of the standard that uses the registry.

4.1.1 Registry Title/NameThe name of this registry is the “_________________________”.

4.1.2 Parent RegistrySpecify the name of the parent registry, if applicable. If there is none, just note “none.”

4.1.3 Information required to create a new value A new entry to the <registry name> requires <describe circumstances where a new value should be created and what is needed to be supplied. While this is often just the content of the row, in some registries, other information is needed to evaluate the proposed new value, and that is described here.

4.1.4 Management PolicyAddition of a new entry requires [explain the process to be used for updating the registry.]

In most cases, you specify one of the management policies defined in NENA-STA-008.1 (formerly 70-001).

Expert Review (or Designated Expert) <- If you use this, you must consult with the DSC chair on who the expert will be. This is the recommended value if adding a value should be relatively easy, but not unconstrained.

NENA Standard Required <- Use this if you want a full NENA STA document to be the only kind of document that can add a value. This is recommended if you want the full review of the value that the NENA document review process for full standards provides

[MM/DD/YYYY] of 16

2829

30342343344345

346347348349350351

352353

354

355356357

358

359

360

361

362

363364365

366

367

368369

370371372

373374375


NENA Document Required <- Use this if you will allow NENA documents other than STA (such as INF) to create a new value. This is recommended if you want a wide review within NENA of the value, but not a public review and not necessarily a full standard.

Document Required <-Use this if any document from any source is acceptable to create a new value. This is recommended if NENA review is not needed, but the values have to be explained in a context that requires a (stable) document be available for implementers to review,

First Come First Served <-Use this if you allow anyone to create a value with no restrictions

Committee Chair Approval <-Use this if you want a political process, rather than an expert process to evaluate the entry.

If none of these work (have you have a good reason why not), describe, clearly, what you want NRS to do instead. NRS reviews this section and may not agree to do what you ask. It’s up to them. Use language similar to that found in ??-???? to describe your management policy. It’s usually okay to do things like make an entry to one registry have some corresponding value in another registry. It’s usually not okay to ask NRS to make some value judgment.

4.1.5 ContentEach entry in this registry contains:

Describe what the columns are. Give them a name, a data type and any restrictions on values. Choose a name that makes an appropriate XML element name. Most registries’ first column is some sort of name or token that is used in some other data structure. Registries’ last column is usually some sort of source (where did the row request come from) as one of the columns. This could be a document reference, or it could be a name of a person or entity that requested the value. Look in other NENA standards for example of well-defined registries.

4.1.6 Initial ValuesList the allowable values for this registry or identify the section # & title in this document where they are identified. This should be a table with all the columns described above.

4.2 New values for [Registry Name] This section is only for adding values to an existing registry.NRS is requested to add new values to the existing registry, <Registry Name>.

Specify the content of all required columns. If you are adding a small number of rows, it is fine to describe the addition like:

Add a new widget with name as “foo”, index as “23” and source as <this document>

The latter will request NRS to use the final NENA document identifier as the value in the registry (and will also cause the editorial staff to replace “<this document>” with the actual document identifier when the document is published.

[MM/DD/YYYY] of 16

3132

33376377378

379380381382

383

384385

386387388389390

391

392

393394395396397398

399

400401

402

403

404405

406

407408409


5 Documentation Required for the Development of a NENA XML SchemaIf this section is not applicable in any given document, simply enter “Not Applicable” in this section. Refer to Exhibit A: Example of Section 5 for an example of how this section should appear.

5.1 Schema NameProvide a name for the schema in PascalCase.

5.2 Schema PurposeA brief description of the how the schema would be used.

5.3 Parent ElementThe name of a parent element. Note: If more than one parent element is expected, repeat the Parent Element and subsequent Child Element sections, again, for each parent element. In the example diagram below DateRangeRequest is the Parent element. A description of the Parent Element including how it will be used must be included.

5.4 Child ElementsComplete the form below, specifying the details of this parent’s child elements. In the example diagram above StartDateTime and EndDateTime are Child Elements.

ELEMENT DESCRIPTION

OCCURS DATA TYPE DATA DESCRIPTION

Element Name Here

1 or 1…* or 0…1 or 0…* or X

A or AN or N or D or S1 or URI or URL

Description of the element name including an example.

Element Name Here

1 or 1…* or 0…1 or 0…* or X



1 Name of sub-element must also be included2 Name of sub-element must also be included

[MM/DD/YYYY] of 16

3435

36410

411412

413

414

415

416

417

418419420421422

423

425

426427428

3738


Element Name Here

1 or 1…* or 0…1 or 0…* or X



5.5 WSDL NeededYes or No

5.6 XML Example(s)A snippet of XML to provide the developer of the schema with a better picture for the intended XML structure. It should be noted that the XML provided is for schema development purposes only, not for developers to build their XML structures.

5.7 Additional NotesAny additional notes that may be helpful to the XML schema developer in the creation of a schema.Notes to reword and place somewhere.

OCCURS is an indication of whether an element is mandatory or optional and the anticipated range of occurrences of the element.

DATA TYPE is an indication of the type of value with the element. A = Alpha, AN = Alphanumeric, N = Numeric, S = Sub Element (sub-element name must also be included) , URI = Uniform

Resource Identifier, URL = Uniform Resource Locator, D = Date (in ISO 8601format).

WG should notify the XML WG of the need for schema development as soon as it is agreed that a schema is necessary. The XML WG will work with the associated WG on the development,

testing and finalization of the schema through document development and subsequent review cycles.

Use of child elements is preferred over attributes of the parent XML element. If attributes are needed the WG should work with the XML WG to identify.

6 Recommended Reading and ReferencesNOTE to document editor: Generally, the reference section of a document will be located at or near the end of the document. It will list all documents or other media used in development of this NENA Standard Document.

7 Previous AcknowledgmentsThis table contains contributors to the most recent previous version. Older documents are available on www.nena.org in the document archives.

NOTE to document editor: Copy the Acknowledgement section from the previous version and paste it here.

[NENA-STA-xxx.x] Executive Board Approval Date, [MM/DD/YYYY]

Members Employer[Committee Co-Chair Name],[Authoring] Committee Co-Chair

[Member employer]

[Committee Co-Chair Name],[Authoring] Committee Co-Chair

[Member employer]

[WG Leader Name], WG Leader [Member employer][WG Member Name] [Member employer][WG Member Name] [Member employer]

3 Name of sub-element must also be included

[MM/DD/YYYY] of 16

3940

41

429

430

431

432433434

435

436437438439440441442443

444

445446447

448

449450

451452

453

42

http://www.nena.org/


[WG Member Name] [Member employer][WG Member Name] [Member employer][WG Member Name] [Member employer][WG Member Name] [Member employer]

Exhibit A: Example of Section 5Schema NameThe name of this schema is StandardBusiness.

Schema PurposeThis schema is used to represent the structure of a standard business unit. It will be used to distribute contact information to clients.

WSDL NeededNo

Parent ElementThe name of this parent element is Division. A Division is a sub-unit of a StandardBusiness.

Child ElementsELEMENT

DESCRIPTIONOCCURS DATA TYPE DATA DESCRIPTION

Department Name 1 A The name of the department.Example: Engineering

Department Role 1…* A The roles associated with the department.Example: Design, Survey, Drafting

Department Head 1…* S One or more Person elements associated with the responsibility of the department.

Parent ElementThe name of this parent element is Person. A Person describes an individual that is associated with the StandardBusiness in some fashion.

Child ElementsELEMENT DESCRIPTION

OCCURS DATA TYPE DATA DESCRIPTION

First Name 1 A The first name of the Person.Example: John

Last Name 1 A The last name of the Person.Example: Doe

[MM/DD/YYYY] of 16

4344

45

454

455456457458459460461462463

465466467

468

469

470471472473

474


Title 1 S The Person’s job title.Example: Director of Engineering

Start Date 0…1 D The Person’s start date.Example: 2014-2-20

XML Example(s)<Division>

<DepartmentName>Engineering</DepartmentName><DepartmentRole>Design</DepartmentRole><DepartmentRole>Survey</DepartmentRole><DepartmentRole>Drafting</DepartmentRole><DepartmentHead>

<Person><FirstName>John</FirstName><LastName>Doe</LastName><Title>Director of Engineering</Title><StartDate>2014-2-20</StartDate>

</Person></Division>

Additional NotesNone at this time.

[MM/DD/YYYY] of 16

4647

48

475476477478479480481482483484485486487488489490

491492493

NENA 01-002 · Web viewUsing “Page Layout” insert the ... This word, or the...

Documents

Transcript of NENA 01-002 · Web viewUsing “Page Layout” insert the ... This word, or the...