A7.6 Registries

A7.7 Semantics

A7.8 UML Modeling

A7.9 Core tML data types

A13. Common Tags—Region 3

A7.1 Schemas

A7.2 Namespaces

A7.3 Vocabulary Standards

A8 tML Namespace Examples (informative)

A10. tML document Examples (informative)

A11. Common Tags—Region 1

A12. Common Tags—Region 2

Standards Contribution

XML aware

XML processor

XML Query Language (XQL)

XPointer

Rules needed for the following:

A6.6 tML in Context of a Complete Trading Partner Specification

A7.4 Conformance

A7.5 Repositories

A6.4 How this Framework will be used

Figure 3. tML in Context of an Implementation Framework

(Shown Using Concept of 7-layer OSI Model)

Note: tML documents/schemas located at Application Layer

Committee T1 – Telecommunications

STANDARDS PROJECT:

TITLE: tML Framework Document

SOURCE: WorldCom, Inc.

CONTACT: Ed White

Tel#: 972-729-5509

Fax#: 972-729-6038

E-mail: ed.white@wcom.com

Editor: Ed White, WorldCom, Inc.

DATE: January 1, 2001

DISTRIBUTION: T1M1

ABSTRACT: This is a Framework for the development of tML (telecommunications Markup Language) standards for the management of telecommunications networks.

Work on this document is being advanced through interim meetings, expert meetings, and weekly meetings via phone-bridge and a Virtual Meeting facility.

This Document has been prepared to assist Standards Committees to advance this work. It is offered to the committee as a basis for discussion and is not a binding proposal on WorldCom. Information presented in this document may be subject to change after more study. WorldCom specifically reserves the right to add to, amend, or to withdraw the statements contained herein.
tML Framework Document

A1.0 Title tML Framework Document

A1.1 Introduction and Background

The eXtensible Markup Language (XML) is a markup language for describing markup languages. XML is subset of Standard Generalized Markup Language (SGML), an open industry standard managed by the WorldWide Web Consortium (W3C). XML specifies neither semantics nor a tag set. Instead, it simply provides a facility to define tags and the structural relationships between them. It was created out of a need for information exchange via the web or via any other mechanism.

The true value of XML is its ability to provide a standard means of exchanging information between applications, business partners, businesses and consumers. It is a critical component in application integration, e-commerce, and document management strategies. Achieving interoperable interfaces using tML requires agreed upon standards for the schema definitions. This framework promotes the use of schemas instead of DTDs.

This document provides a Framework to develop such standards for schema definitions. It provides the information and structure that will maximize the opportunities and benefits that this technology can provide. This document defines guidelines for creating interrelated components of an interoperable interface such as schema definitions (when approved as a W3C Recommendation), vocabulary, and namespaces. The framework meets the following objectives:

Minimize the redundancy in the definition of tags
Define single semantics for each tag
Reuse of the semantics available in TMN information models

The term tML in the context of this standard is a markup language derived from applying XML, a meta‑language used to derive other markup languages. tML receives its name from common telecommunications markup (tag names) defined in this document and from other markup defined in a variety of telecommunications standards developed from using this Framework.

A1.2 Purpose of tML Framework

The purpose of the tML Framework is to provide a standard definition for the development of interoperable interfaces based on the use of the eXtensible Markup Language (XML), within the TMN context. The goal for use of the Framework is to guide the development of tML schemas and vocabularies and to provide a common method for the definition of tML data to be exchanged and to provide a mapping to existing standards to promote re-use whenever possible.

A1.3 Scope

The scope of the tML Framework consists of:

a set of rules and objectives to be applied in developing standardized schemas based on existing models in standards;
specification of common tML tags, namespaces, and URIs;
transformation of existing definitions in external libraries for use with tML; and
requirements for repositories and registries

This document specifies a number of alternative approaches for transferring tML compliant data across a TMN interface. The initial concentration is to support X interface. Even though multiple approaches are noted in this document, it is necessary to choose a specific method for implementing the transport infrastructure in order to exchange the tML documents. The specific approach may be documented in either a future version of this Framework or in a different standard.

The Framework document is organized according to interface types, e.g., TMN X, F, Q, and G interfaces (Figure 2), and there is a general section that includes specifications common to any of the interface types. This version of the document addresses only the X interface. (Add explanation on the differences in the three cases in Figure 2)

A2.0 References

A2.1 WorldWide Web Consortium (W3C) Recommendations

Extensible Markup Language (XML) 1.0 (Second Edition)	W3C Recommendation 6 October 2000
XML Schema Part 0: Primer	W3C Candidate Rec, 22 September 2000
XML Schema Part 1: Structures	W3C Candidate Rec 22 September 2000
XML Schema Part 2: Datatypes	W3C Candidate Rec 22 September 2000
Draft--Extensible Stylesheet Language (XSL) Version 1.0	W3C Working Draft 18 October 2000
Document Object Model (DOM) Level 2 Core Specification--Version 1.0	W3C Recommendation
XML Linking Language (XLink) Version 1.0	W3C Candidate Recommendation 3 July 2000
XML Pointer Language (XPointer) Version 1.0	W3C Candidate Recommendation 7 June 2000
Draft--XSL Transformations Requirements Version 1.1	W3C Working Draft 25 August 2000
Namespaces in XML	W3C Recommendation 14-Jan-1999

Note: W3C publishes several types of technical reports:

· Notes--A Note is a dated, public record of an idea, comment, or document. A Note does not represent commitment by W3C to pursue work related to the Note.

· Working Drafts--A Working Draft represents work in progress and a commitment by W3C to pursue work in this area. A Working Draft does not imply consensus by a group or W3C.

· Candidate Recommendations--A Candidate Recommendation is work that has received significant review from its immediate technical community. It is an explicit call to those outside of the related Working Groups or the W3C itself for implementation and technical feedback.

· Proposed Recommendations--A Proposed Recommendation is work that (1) represents consensus within the group that produced it and (2) has

· been proposed by the Director to the Advisory Committee for review.

· Recommendations--A Recommendation is work that represents consensus within W3C and has the Director’s stamp of approval. W3C considers that the ideas or technology specified by a Recommendation are appropriate for widespread deployment and promote W3C’s mission.

A2.2 IETF Specifications

References to be added

A2.3 OMG

References to be added

A2.4 ITU-T Recommendations

References to be added

A2.5 ISO Standards

ISO/IEC 9646-7:1995 (ITU-T Rec. X.296 (1994)), Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 7. Implementation conformance statements.

A3.0 Definitions

Attribute

a property of an element; because they can pass information about an element they can be viewed as metadata for the element. Composed structurally as name=value pair, where name is the name of the attribute and value is the value of the attribute

Cascading Style Sheets (CSS)

a mechanism that allows authors and readers to attach rendering characteristics (e.g. fonts, colors, and spacing) to HTML and XML documents

Channel Definition Format

an open specification that permits a web publisher to offer frequently updated collections of information, or channels, from any web server for automatic delivery to compatible receiver programs on PCs or other information appliances.

Channel Definition Format

an open specification submitted to W3C that permits a web publisher to offer frequently updated collections of information, or channels, from any web server for automatic delivery to compatible receiver programs on PCs or other information appliances. CDF is still proprietary.

Character

an atomic unit of text as specified by ISO/IEC 10646; a single alpha, numeric, or punctuation mark.

Character data

all text characters that are not markup characters

tags (domain specific)

Names for elements, attributes or entities that are unambiguous within a specific tML environment (e.g., X, Q, F, G)

tags (common-global)

Names for elements, attributes or entities that are unambiguous and are globally unique across all tML domains

Content

all data between the start tag and end tag of an element; may be made up of markup characters and character data.

Delimiter

a special character that marks the beginning and end of a string or text field

Document

a class of data object; may be the text of a printed document, a set of database records,

Document Object Model (DOM)

a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page

Electronic Data Interchange (EDI)

the electronic exchange of information between two business concerns (trading partners), in a specific predetermined format implemented as transaction sets. Exchanges typically relate to standard business documents, such as purchase orders and customer invoices.

Element

a logical data structure within an XML document; start tags and end tags define the beginning and end of an element.

Empty element

elements that do not have content. Empty elements may be noted with a special empty element tag that ends with a forward slash directly preceding the closing angle bracket of the tag (<empty/>).

Entity

a virtual storage unit of no fixed value, identified by a name; often a separate file, but may be a string or even a database record.

Extensible HyperText Markup Language (XHTML)

an approved W3C Recommendation that is the “XML-ization of HTML”. Essentially XHTML is the “newest version” of HTML. XHTML extends its functionality of HTML to support a wider range of devices and applications. XHTML 1.0 is a reformulation of HTML 4.0 as an XML 1.0 application. The W3C plans to provide tools to convert HTML documents into valid XHTML.

Extensible Linking Language (XLL)

the standard for describing links among objects in XML documents. (See XLink.)

Extensible Markup Language (XML)

a subset of ISO 8879, Standard Generalized Markup Language (SGML). The XML subset of SGML has been specifically designed to function on the Web. A data format for structured document interchange that is more flexible than HTML. While HTML’s tags are predefined, XML allows tags to be defined by the developer of the page. Thus, XML-defined Web pages can function like database records.

Extensible Style Language (XSL)

the style standard for XML. Like CSS, it specifies the presentation and appearance of an XML document.

Framework

a structure composed of a set of related architectural components

Generic identifier

The name of the element’s type, e.g., <title> has a GI equal to "title". A GI is unique in its namespace.

HyperText Markup Language (HTML)

a system of coding information from a wide range of domains (e.g., text, graphics, database query results) for display by World Wide Web browsers. Certain special codes, called tags, are embedded in the document so that the browser can be told how to render the information

Implementation Framework

a set of related specifications or architectural components applied to convey tML documents between entities

Internet Engineering Task Force (IETF)

a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual. The IETF publishes Requests for Comments and specifications.

Meta-data

data that describes other data. Important metadata specifications include channel definition format (CDF), resource description framework (RDF), and topic maps.

Meta-language

a language that describes other languages. SGML and XML are considered meta‑languages because they define markup languages.

Organization for Advancement of Structured Information Systems (OASIS)

a nonprofit, international consortium dedicated to accelerating the adoption of product-independent formats based on public standards. These standards include SGML, XML, HTML and CGM as well as others that are related to structured information processing. Members of OASIS are providers, users and specialists of the technologies that make these standards work in practice.

Parent element

an element containing other elements; the elements contained within the parent element are known as child elements.

Registry

in the context of this specification, the location of metadata about a repository. A registry is provided for users who want to locate schemas, owners of schemas, and other information stored in a repository.

Repository

one or more globally distributed locations used to store schemas, names and locations of schema owners, UML models, and other data and constructs needed to facilitate interoperable exchanges of information between entities

Resource Description Framework (RDF)

a W3C Proposed Recommendation. RDF is a foundation for processing metadata; it provides interoperability between applications that exchange machine‑understandable information on the Web. RDF uses XML to exchange descriptions of Web resources but the resources being described can be of any type, including XML and non-XML resources.

Root element

one element that contains all other elements of the document; the root element is also called the document element.

Schema

a term derived from a description of the tables and fields and the relationships between them in a relational database system. Schemas represent a model for the content of XML documents. Schemas provide for primitive data typing; define a type system that is adequate for import/export from database systems; allow creation of user-defined datatypes; allow datatypes that are derived from existing datatypes; allow constraints on certain properties (e.g., range, precision, length, format).

Simple API for XML (SAX)

an event-based API for parsing XML documents.

There are two major types of XML APIs: A tree-based API compiles an XML document into an internal tree structure, then allows an application to navigate that tree. An event‑based API, on the other hand, reports parsing events (such as the start and end of elements) directly to the application through callbacks, and does not usually build an internal tree.

Standard Generalized Markup Language (ISO 8879)

a meta-language used to construct other markup languages. XML is a simple dialect of SGML, sometimes referred to as SGML‑lite.

Synchronized Multimedia Integration Language (SMIL)

an XML-based language that allows developers to create synchronized multimedia presentations for the Web, providing audio, video, graphics over various connections (even including 28.8 Kbps or 33.6 Kbps); a W3C full recommendation, approved in June 1998

any software application that recognizes the XML data format and understands XML concepts

XML declaration

· an optional declaration at the top of an XML document that specifies the version of XML and an encoding declaration.

XML derivative

any dialect of XML defined by a DTD that is designed to support a specialized purpose, or vertical market; examples are CML (Chemical Markup Language), MathML, FPML (financial products markup language), and WML (wireless markup language)

XML dialect

Same as XML derivative

XML editors

software that allows basic data/metadata editing functions and explicit control over XML markup.

XML entities

special sets of characters that help expand document content without increasing the overall character count; internal entities act as typing shortcuts or macros; external entities incorporate content from outside sources into the main document.

XML Metadata Interchange (XMI)

an open information interchange model intended to give developers working with object technology the ability to exchange programming data over the Internet in a standardized way, bringing consistency and compatibility to applications created in collaborative environments. XMI is intended for storage in a traditional file system or for streaming across the Internet from a database or repository. The XML Metadata Interchange Format (XMI) specifies an open information interchange model that is intended to give developers working with object technology the ability to exchange programming data over the Internet in a standardized way, thus bringing consistency and compatibility to applications created in collaborative environments. By establishing an industry standard for storing and sharing object‑programming information, development teams using various tools from multiple vendors can still collaborate on applications. XMI is a standard of the OMG (Object Management Group), adopted in March 1999.

XML Namespace

a set of unique identifiers; a way of defining each element type and attribute name in an XML document unambiguously (through associations with specific URIs) so that two or more XML‑based languages may be used in that document without creating a conflict.

XML Parser

a processor that reads an XML document and determines the structure and properties of the data. If the parser goes beyond the XML rules for well-formedness and validates the document against an XML DTD, the parser is said to be a "validating" parser.

a software module that reads XML documents and provides access to their content and structure. The processor does its work on behalf of another module, called the application. The processor reads the XML data and provides the application with the information.

a notation for addressing and filtering the elements and text of XML documents; provides a concise, understandable notation for pointing to specific elements and for searching for nodes with particular characteristics.

XML Schema

provide a means for defining the

structure, content and semantics of XML documents. express shared vocabularies and allow machines to carry out rules made by people. A W3C candidate Recommendation.

XML vocabulary

an XML tag set with a specific functionality. tML, WML, and MathML are all examples of XML vocabularies.

XPath

a way of referencing information within an XML document, intended as a bridge between XPointer and XSLT. XPath uses a directory notation to perform queries through the selectNodes??? architecture and lets you determine which elements within an XML document satisfy a given set of criteria.

W3C Candidate Recommendation based on XPath; issues an XML document node to an Xpath component based on the hierarchical document structure and various properties, such as element types, attribute values, character content, and relative position.

In its simplest form it allows one to refer to a particular element named with an “id” in an XML document; e.g., one can refer to “welldone” in an XML document using the following example: http://www.steaktown.com/prepare.xml#xptr( id(“welldone”) )

XSL

specifies the styling of an XML document by using XSLT to describe how the document is transformed into another XML document that uses the formatting vocabulary

XSL Transformation Language (XSLT)

a language used to transform (reformat) XML documents into other XML documents; designed for use as part of XSL, which is a style sheet language for XML but is designed so that it can be used independently of XSL; not intended to function as a general‑purpose XML transformation language; makes use of the expression language defined by XPath for selecting elements for processing, for conditional processing and for generating text.

A4.0 Abbreviations

API	Application Program Interface
CDF
CSS	Cascading Style Sheet
DOM	Document Object Model
DTD	Document Type Definition
EDI	Electronic data Interchange
GI	Generic Identifier
HTML	HyperText Markup language
HTTP	HyperText Transfer Protocol
IETF	Internet Engineering TaskForce
ISO	International Organization for Standardization
ITU-T	International Telecommunication Union-Telecommunication
OAM&P	Operation Administration Maintenance & Provisioning
RDF	Resource Description Framework
SAX	Simple API for XML document
SGML	Standard Generalized Markup Language
SMIL
SOX
tML	Telecommunications Markup Language
UML	Unified Modeling Language
URI	Uniform Resource Identifier
URL	Uniform Resource Locator
URN	Uniform Resource name
W3C	WorldWide Web Consortium
XHTML	eXtensible HyperText Markup Language
Xlink	XML Linking Language
XMI	XML Metadata Interchange
XML	eXtensible Markup language
Xpath	XML Path Language
Xpointer	XML Pointer Language
XQL	eXtensible Query language
XSL	eXtensible Stylesheet Language
XSLT	XSL Transformation

A5.0 Conventions

A6.0 Discussion

A6.1 Goals for the Framework Document

Provide guidance for development of interoperable OAM&P interfaces using TMN domain specific applications of XML
Be applicable to various telecommunications OAM&P domains

· Facilitate multiple telecom industry fora to use a common framework in developing network management specifications using tML

A6.2 Contexts in which the tML Framework should be used

Figure 1. tML Framework as Component of a Complete Trading Partner Specification

A6.3 The tML X interface applications in the context of ebXML functionality

(from interim meeting 5 Dec 00)

This version of the tML Framework focuses on TMN X interface services. The following table maps X interface services to the ebXML model found in version 0.9 of ebXML Architecture Specification, Figure 1 in Section 8.0.

The ebXML model assumes that an industry body has populated the registry with specifications, scenarios and business profiles. The analogous step would be for the standards bodies to populate a registry with similar information on X interface specifications with tML.

Note:

ebXML—electronic business XML

TA—Trouble Administration

PIC—Primary Inter-exchange Carrier

EAO—Electronic Access Ordering

LOPO—Local Ordering/Pre-Ordering

(need to complete LOPO)

ebXML interaction (Functionality)	TA B leases service from A and needs to report troubles	PIC B is the access customer requesting a PIC change from A, the access provider	EAO B is the access customer requesting access from A, the access provider	LOPO
(1) A Requests ebXML spec	A requests a copy of trouble report admin specification (e.g. X.790) with the information model	A requests a copy of PIC specification (e.g.T1.246) with the information model	A requests copy of EAO specification (e.g., T1.256) with the information model
(2) A Receives ebXML spec details	A receives a copy of the spec (electronic or otherwise)	A receives a copy of the spec (electronic or otherwise)	A receives a copy of the spec (electronic or otherwise)
(3) A builds local system implementation	A develops a gateway to its existing Trouble report system such as WFA or LMOS or creates a new trouble report system	A develops a gateway to its existing switch administration system or creates a new system	A develops a gateway to its existing trunk administration system or creates a new system
(4) A submits scenarios, implementation details and company business profile	A makes available the implemented subset, the set of leased services, SLA (or in the future provide this to a registry)	A makes available the implemented subset of PIC services and SLA (or in the future provide this to a registry)	A makes available the implemented subset of EAO access services and SLA (or in the future provide this to a registry)
(5) Registry confirms that profiles and scenarios are accepted	If registry approach is chosen then the registry sends a response; else no action	If registry approach is chosen then the registry sends a response; else no action	If registry approach is chosen then the registry sends a response; else no action
(6) B queries registry for A’s profile	B requests A or registry for SLA information.	B requests A or registry for SLA information.	B requests A or registry for SLA information.	B requests A or registry for SLA information.
(7) Registry returns A’s profile details	A or the registry returns the requested SLA	A or the registry returns the requested SLA	A or the registry returns the requested SLA	A or the registry returns the requested SLA
(8) B submits trading partner agreement to A	B negotiates the details of SLA with A	B negotiates the details of SLA with A	B negotiates the details of SLA with A	B negotiates the details of SLA with A
(9) A confirms that TPA details are accepted	A and B come to a common agreement on SLA.	A and B come to a common agreement on SLA.	A and B come to a common agreement on SLA.	A and B come to a common agreement on SLA.
(10) B requests A’s scenario details from registry	B requests information such as trouble report formats, range of trouble codes, trouble status and other appropriate information implemented by A.	B requests information such as supported TCSI codes and parameters associated with those codes implemented by A.	B requests information such as supported field values on the ASR implemented by A	B requests information such as supported TCSI codes and parameters associated with those codes implemented by A.
(11) Registry returns A’s scenario details	Either A or the registry answers the request.	Either A or the registry answers the request.	Either A or the registry answers the request.	Either A or the registry answers the request.
(12) B and A do business transaction	B sends A trouble reports and performs electronic bonding using tML syntax. NOTE – Only step 12 is where the interaction is dynamic and corresponds to instances of communications. All other steps are precursors required and performed as implementation agreements.	B sends A PIC changes for end customers and performs electronic bonding using tML syntax. NOTE – Only step 12 is where the interaction is dynamic and corresponds to instances of communications. All other steps are precursors required and performed as implementation agreements.	B sends A an ASR and B responds with FOC and DLR using tML syntax. NOTE – Only step 12 is where the interaction is dynamic and corresponds to instances of communications. All other steps are precursors required and performed as implementation agreements.

· Rules for defining tML tags and vocabularies

· Rules for Namespaces

· Rules for security

· Rules for modularity and reuse

· Definition of common elements used across all tML domains

· Repository and registry use requirements and recommendations

· Support for Stylesheets (CSS and XSL)

· Recommendations for use of Unified Modeling Language (UML)

Figure 2. tML Framework partitioning

A6.5 Domains Proposed for tML

TMN X interface (section 7 contains Rules and Objectives)
TMN Q interface

· TMN F interface

TMN G interface

Note: this version of the tML Framework focuses on the TMN X-interface

The extent of influence of the tML Framework is bounded as described in the Scope section. However, the work products created by using the tML Framework may be viewed within contexts that must be considered or present for these work products to be useful:

1. In the context of a complete trading partner specification (Figure 1)

2. In the context of an Implementation Framework (Figure 3)

For the tML to be useful, trading partners (in the case of X interface applications) must have in place a “complete trading partner specification” (see Figure 1) of information interchange. A complete specification would include business driven process definitions, schema definitions using the data and vocabulary definitions, and an implementation framework.

Business Driven Process Definitions—The business process portion of a complete trading parner specification for information interchange may include activities, decision trees, and roles for each entity trading information. A UML model may be developed to describe these business driven processes. Such a model may include use cases, collaboration diagrams, sequence diagrams, and possibly statechart diagrams. Such business process definitions and related activities are out of scope for this Framework standard.

Data and Vocabulary—The tML Framework supports definition of domain-specific data and vocabulary (markup) for separate tML standards. These data and vocabularies may be extensions of those defined in this standard, they may newly developed, or they may be extensions of data and vocabularies found in vertical industry business‑to‑business (B2B) repositories.

Implementation Framework— Part of a complete trading partner specification of information interchange is an implementation framework (or IF). The tML Framework (shown as a block in Figure 1) is a component of an IF. Specification of IFs is not in the scope of this tML Framework standard. IFs are already defined in certain standards or elsewhere. As time goes on, other IFs will be defined for the TMN in telecommunications applications and for the business‑to‑business (B2B) industry for Internet applications. These new IFs will be available for architects, designers and implementers to specify in support of tML.

A complete implementation framework standard would be selected through a trading partner agreement[1]. Such an agreement would include specifications of the message structure (envelope, header, message payload), protocol, reliable connectivity, and security. The tML application (i.e., the tML document content) would be applied in the message payload section of such an IF.

Figure 3 shows tML in the context of an IF using the concept of a seven-layer OSI model. Please note that this standard does not specify such an OSI model. The OSI model is used here only to conceptualize how an IF might be constructed. Using this conceptual OSI model we can show that tML documents and schemas are exchanged at the application layer, i.e., layer 7.

A complete specification for information exchange would include:

® is a requirement, (O) is an objective, Bold means tML compliance

® Business drivers (may be from OBF, ECIC, Unified Ordering Model (UOM) process, or elsewhere), including answer to “why does XML solve this need”

® Process model (derived from OBF, ECIC, UOM process, or elsewhere)

® Functional requirements (may be from OBF, ECIC, UOM process, or elsewhere)

® Data and vocabulary definitions

® Semantics definitions, or reference to such definitions (may be from OBF, ECIC, UOM process, or elsewhere)

® XML Schema specifications

® References to any external schemas

® References to any common tags defined in tML Framework

® Namespace specifications

® Repository requirements specific to telecommunications

® Repository requirements, if any, specific to general e-commerce

® Registration requirements (associated with Repository requirements)

® Recommended Implementation Framework (IF)

(O) UML diagrams (either in the document or in a reference document)

(O) UOM reference

(O) Compliance specifications

(O) Conformance testing recommendations

(O) Security requirements

(O) Reference to any trading partner agreements* supporting the proposed tML standard

*agreements may contain the following

Identification of document describing agreement between parties
Communication protocols to be used
Security requirements
Data definition and formats
Semantic definitions
Definition of roles of all trading partners
Definition of when a message is legally considered received
Request/response actions each trading partner can make
Transactions each trading partner can perform
Recovery procedures
Responsiveness

· Dispute resolution procedures

The tML Framework contains of two sets of common (core) vocabulary: 1) a core vocabulary set that applies to all tML documents and 2) core sets of domain‑specific vocabulary. It is the core vocabulary (markup) specified in this Framework that gives tML its name.

As tML standards are developed using this Framework, the resulting vocabulary may be referred to as something different than “tML”, perhaps according to the domain name, e.g., SONET-ML, ATM-ML, Q3ML, etc., or simply tML-a, tML-b, tML-c,.., etc. Domain specific markup language extensions to tML will continue to be developed as long as new telecom services and new network element and operational support system technologies continue to surface.

A7.0 Generic Rules and Objectives

Unlike HTML and its finite set of markup tags, XML allows for creation of a (unique and unlimited) set of tags and data constructs that facilitate the exchange of information, and provides a facility to define rules that control how an XML document is structured. These rules and formatting requirements are used in developing a schema.

Rule 1. All tML documents shall use tML schemas to describe document structure.

tML schemas may contain references to schemas in external (non-tML) repositories

The extensibility of XML allows creation of tML documents specific to the problem domain of the user through specification of tags and content unique to an application. In the absence of a schema, a tML document cannot be validated for a specific application.

Rule 2. tML schemas shall be made available for external use

USA will be creating schemas specific to their problem domains. As these external schemas appear and are formalized for the industry, they should be made available for reference and reuse from a public repository when applicable.

Objective 1. Applications may employ validating parsers in production to process tML documents.

The choice of whether to use a validating or non-validating parser is dependent on a variety of factors including run-time performance and prior up-stream validation

Objective 2. Every schema should contain comments documenting the structure and content of the tML documents described by that schema.

While careful choice of tag names[2] lends readability to the tML document, judicious use of comments within a schema definition and/or tML document can greatly extend the understanding of the schema.

****Find a home for this?: <It is anticipated that the unique root namespace will be based on a public e-commerce URI. Incorporated in the namespace will be an extension of “tML”. Selection of root tbd>

See Appendix A for Namespace examples (non-normative)

***

An XML namespace is a collection of element type and attribute names each identified by a unique two-part name. The first part of the name is a prefix representing the URI (Uniform Resource Identifier) of the XML namespace from which the element or attribute has been imported. The second part is the element type or attribute name itself. Together, the prefix and the element type/attribute name form the uniform name.

Rule 3: All tML documents shall declare (i.e. use) default namespaces appropriate for the application.

Rule 3B: A particular namespace shall be defined in only one tML document.

If an element type or attribute name is not specifically declared to be in a tML namespace, i.e. it has no prefix, by definition it is in the default tML namespace. Failure to define a default namespace or qualify a tag would limit the reusability of the tML document outside of its initial implementation.

tML namespace declarations that are made on the root element are in scope for all elements and attributes in the document.

Rule 4. Avoid overriding any default namespace. Doing so will make managing namespaces difficult to read and maintain.

(*** Note - add an example to make it clear. Is the prefix noted here the URI? Can we have a BNF formalism to explain these terms?)

Rule 5. Use a unique prefix for each tML namespace.

This standard helps to ensure readability and support of the tML schema as well as to ensure schema integration. Prefixes, like URIs, should be unique when identifying a set of tags. Documents that use multiple prefixes for the same tML namespace or the same prefix for multiple tML namespaces are confusing to read and thus prone to error. They also allow abuses such as defining an element type or attribute with a given universal name more than once.

Rule 6. Do not use more than one prefix per tML namespace.

Because the prefix is just a proxy for the URI, it is possible to have a universal namespace while re-implementing the same prefix. This practice, while technically allowable, would reduce the readability of the tML document and lead only to later confusion and support issues. Needs clarification vs. #3

Rule 7. Namespaces and their prefixes must follow the standard naming convention.

By following the standard naming convention one can ensure that element tags will be compatible, reusable, and verifiable by schemas. (reference needed for standard naming convention). The creation of both the namespace and schema must produce the same unique qualified name for each tag defined.

Namespace URIs should use the following syntax:

Origination.Business Function.Information Area.Identifier/Version

Where:

· Origination – source of the schema. Note that this will be documented in the metadata of the schema.

· Business Function – The type of business process or vertical industry area (e.g. billing) that the namespace applies to.

· Identifier – A code that is supplied to each namespace by the Steward to ensure uniqueness.

· Version – The version number, incremented each time a new version of the namespace/schema is created. Backward compatibility issue if we use this?

The following example: would designate a namespace to version 03 of fictitious schema containing customer address information for the Trouble business function:

tML.TroubleAdministration. X790/03

Namespace Prefixes should use the following syntax: Origination|Business Function abbreviation. Standard abbreviations must be used. The prefix used for the URI listed above would be:

tMLTA

Rule 8. Declare xmlns attributes in the schema and use the same qualified names in the schema as in the body of the tML document.

The XML keyword, xmlns, stands for “xml namespace” and is followed by an attribute that is the name of a namespace. For tML documents to be both valid and conform to the XML namespaces recommendation, one needs to declare any xmlns attributes and use the same qualified names in the DTD as in the body of the document

Each markup language generated in XML has its own vocabulary of tags that describe the information being conveyed. This section includes standards for the development and use of tags within the tML Framework.

Rule 9. Common tags shall be maintained by a content manager.

Tags designate the data elements, and the attributes that belong to them, used in applications or data formats. Both sender and receiver must agree on tag nomenclature and the rules for formatting messages and for accepting them (e.g. "customer number," versus "customer #", "cust#", "customernum”, or "custnum"). The content manager will help ensure the development and control of a relatively small, and well-documented, set of common tags that are commonly understood and universally used. One must search for and reuse any common tags that may already exist before they work on creating new ones. Having a content manager, a central person who is responsible for all common tags used in an application, will ensure that all element and attribute tags are defined, reduce the risk and problems associated with redundancy and translation, and facilitate reuse.

Rule 10. Metadata for all tags shall be documented and stored in a publicly identified repository.

The consistent use of tags across tML documents requires a repository that can be consulted for previously defined and standardized tags. Required documentation must be maintained in the repository under appropriate change management procedures, and published in an accessible format.

Metadata for tags

· Tag Name [r]

· Full Name [o if the Tag Name uses abbreviations]

· Member of which schema(s) [r]

· Definition [r]

· Version/date [r]

· Custodian (content manager) [o]

· Organization [r]

· Attributes (value sets) [r]

· Edit rules [o]

· Equivalent tML tag if this is an external tag [o]

[r = required; o= optional]

It must be possible to understand explicitly what is meant by each tag, and what attributes it has, including what data values are “included” and what data values are “excluded”.

The repository vocabulary interface must facilitate storage and retrieval of information by anyone with a need to know.

Rule 11. need discussion on rules/objectives for attribute use in tML.

Guidelines for using attributes:

Attributes are good for holding descriptive information about the element they are associated with. If the reader wants to see the information, use elements; if not, use attributes. Metadata such as ID numbers, URLs, references, and other information not directly relevant to the document reader should be placed in attributes.

Attribute example:

<!ELEMENT composer (name)>

<!ATTLIST composer id ID #REQUIRED>

<!—id is an attribute of composer that must always be filled in -->

schema

<composer id="c2"> <name> Jeff Jones</name> </composer>

XML

Consider this sample XML (obtained from the W3C Activity Statement on May 5, 2000):

<customer-details id=”AcPharm39156”>

<name>Acme Pharmaceuticals Co.</name>

<address country=”US”

<street>7301 Smokey Boulevard</street>

<city>Smallville</city>

<state>Indiana</state>

</address>

</customer-details>

The repository must include a description of the allowable sets for the country attribute -“CAN”, “US”, or “UK”, etc. However, this means of handling appropriate information only works within the DTD. [3]

Rule 12. New tags may only be created if they are unique to the business area.

One must ensure that multiple tags are not developed to cover the same information without justification. For example, if there is a proposal for a client tag, and the definition reveals that this will hold the same information as in an existing customer tag developed by a different team, the tag developer must ensure that only one is used. Tag names should follow the data naming conventions to be determined by the tML Framework initiative.

Rule 13. No tag may be used for multiple (unrelated) meanings.

Accurate and complete definitions of schemas and tags are critical. The same tag should never be used in different ways within an application. The same tag name should never be used for an attribute of an element and a child element of the same element.

The content manager has the responsibility for ensuring that no tag is used for purposes outside of its definition. For example if the tag address has been defined as a location identifier it can be used for a customer’s address, a delivery address, etc., but not for an “address” that a speaker has given to an audience:

<speaker>Abraham Lincoln</speaker>

<address>The White House</address>

<address>Gettysburg Address</address>

Guidelines for avoiding name collisions:

Note that Namespaces allow developers to uniquely qualify element names and relationships and to avoid name collisions on elements that have the same name but are defined in different vocabularies.[4]

Example:

<?xml version="1.0"?>
<story:books xmlns:EInvtryBook='uri:E.Inventory.Book.x100/01'

xmlns:EInvtryAuth='uri:E.Inventory.Author.x200/01'>

<EInvtryBook:name>Cheaper by the Dozen</EInvtryBook:name>
<EInvtryAuth:name>Jane Doe</EInvtryAuth:name>

</story:books>

Rule 14. When schemas from external sources are selected for use by an application, the Steward must be the contact point between the owners of the external schema and the owner of the tML Framework specification.

tML schemas need to be registered in the repository. This will enable application teams considering the use of tML to determine what schemas are in existence and whether an existing schema can meet their needs.

Guidelines for using entities:

Entity references offer a number of benefits:

The ability to define commonly used text in a single location.

The ability to break large documents up into workable modules.

Provide one possible foundation for a reuse strategy.

For example, you may have your letterhead saved as an entity in a shared file. Then, every time you write a letter in XML, you could use an internal entity, &letterhead, that would expand to:

My Company

1234 Fifth Ave.

Suite 1256

Los Angeles, California 90026

Using &letterhead would eliminate typos, which XML validation would not catch, reduce redundancy, and facilitate updates/change management.

Objective 3. Conformance testing should be performed to determine if a draft tML standard is in compliance with this Framework document

Objective 4. Conformance testing should be performed between entities to determine if they comply with a tML standard.

tML standards will be developed as a result of applying this Framework recommendation. Implementations of these standards will be subjected to testing prior to being deployed.

Basically there are two approaches to testing tML implementations to ensure that they work effectively together.

One approach is conformance testing, in which a single implementation is compared to a tML standard to be sure that the implementation does what the tML standard specifies; the theory behind conformance testing is that if implementations all conform to the abstract standard they should interoperate with each other, although in practice this may not necessarily be the case.

The other approach is interoperability testing in which two or more implementations are tested directly against each other with the tML standard used, primarily, as a reference to adjudicate problems and incompatibilities, and, secondarily, as a guide to the functions to be tested and the general behavior to be expected. The objectives and expected results of these two types of testing are somewhat different.

Notwithstanding any standard or framework recommendation, implementers of tML standards will test if, and will ensure that, the implementations interoperate with each other. However, it is an objective that implementers, in conjunction with vendors, perform both types of tests. In this fashion, test results will help to support the theory that other implementers will be successful in performing interoperability testing of the same tML standard.

A form similar in concept to a protocol implementation conformance statement (PICS) may be applied to express conformance with a tML standard based on this tML Framework specification. An example of such a form is shown in the figure below. The PICS type of form is based on an ISO standard “ISO 9646 – Conformance Testing Methodology and Framework”. Part 7 of ISO 9646 (Implementation Conformance Statements), addresses the implementation of a PICS.

When developing a PICS effort a PICS proforma will be supplied for completion by the person or organization (the client) requesting conformance testing. The proforma may be written in the form of a questionnaire or a table (example shown below), that, when completed for a tML implementation, becomes the PICS (see ISO/IEC 9646-1).

*mandatory (m), optional (o), not applicable (na)

where:

Item—the number of the line item under consideration

Capability Description or Does the Item Support—

Ref.—

Status—

Support Y/N/na—

Values Allowed—

Values Supported—

As tML usage proliferates, one could likely expect a similar proliferation of schemas. There will be inevitable overlap between tML documents, whereby content of two or more documents references the same data. In this case, a single schema could describe the content and structure of these tML documents. To prevent duplication, achieve the expected benefits from this technology, and ensure consistency in naming and document structure, schemass must be maintained in a generally available repository. An interface will be defined to an enterprise catalog site that will be maintained for registering schemas (and tags) and storing related metadata. Required documentation must be maintained in the repository under appropriate change management procedures, and published in an accessible format.

Metadata for schemas

· Schema Name [r]

· Used by [r]

· Definition and intended use [r]

· Version/date [r]

· Content manager [r]

· Organization/Body [r]

· Storage location of schema (url) [r]

[r = required; o= optional]

The registry interface must facilitate storage and retrieval of information by anyone with a need to know.

Rule 15. Repositories shall conform to the following requirements…

Repository characteristics and services
Availability
Reliability
Security (access rights,
Interworking between dialects
Must be accessible by TMN

Repository should contain the following:

Schemas
UML models behind the schemas
XSL translations from one dialect to another
Logging of how many are using the Repository and how many are using what schemas
Schema search (and what capabilities a trading partner has)
Schema listings
Trading partner profiles
See Sec 20.4 of ebXML doc

Methods of adding to Repository

Should contain a list of common tags and definitions (semantics)

Links must be given to sources of external schemas

Reuse of existing repositories, libraries

Management of Repository (as a service), including backup and recovery (administrivia)

Version Control/configuration management

Does tML need a local copy of external repository and if so how does this get updated automatically through a service from maintenance agent? Same from tML repository to a user.

Access via various indexes, single API?? Repository in ebXML will not support dynamic access (i.e., won't support realtime). Make “access methods” a section of RFI.

Process of putting schema in repository to make it publicly available

Process of using existing schemas

UML to various mappings (e.g., XML, IDL). Map UML to Schemas with a toolkit

Rule 16. tML standards shall identify mechanisms that provide pointers to repositories containing related interface definitions such as schemas, semantic models, transformations, DOM models, etc.

There may be numerous repositories available to the user of a tML standard. Mechanisms must be created so that the user of a repository or repositories is able to resolve the location of each repository containing the data they are looking for. This mechanism is called a registry. A registry contains metadata (data about data).

Rule 17. tML standards shall provide agreed semantic models that define meaning, behavioral aspects of tML tags

It is important to reach agreement on what tML tags mean. For example, in one business entity “do not make the service available before date x” may mean that the party placing the order need not accept the order if it comes too soon, whereas in another business entity the same semantic may have a different meaning. Just because two business entities that are to communicate with each other agree on a tag, it does not mean that they have also agreed (yet) on the semantics associated with the tag.

To the extent possible, the telecommunications industry should attempt to adopt semantic meaning from initiatives and consortia that have already defined the semantics. Examples are ebXML, RosettaNet, ANSI X12, and OASIS. These initiatives can supply semantics for some of the more generic aspects of tML. Furthermore, choreographies exclusive to telecommunications should be defined and stored in centralized facilities, e.g., repositories.

Objective 5. The Unified Modeling Language may be used to define the semantics and data models for business processes specific to the telecommunications domains using the tML.

Rule 18. …

A7.10 Security

Rule 19. …

A8.1 EXAMPLE 1:

An XML namespace is a collection of elements or attributes. It is uniquely identified by an Universal Resource Identifier (URI). The

Let says in the tml domain, there are 2 namespaces defined in the two schemas tmlCommon.xsd and tmlX790.xsd which can be referenced by the URI respectively,

http://www.xxx.org/tml/tmlcommon.xsd

http://www.xxx.org/tml/tmlX790.xsd

(note: a URI does not have to be URL. In this example, it is assumed that HTTP is used to retrieve the information)

• tmlCommon.xsd contains elements or attributes that are common to all tML business functions. The elements are Telephone, Name, etc…

• tmlX790.xsd contains elements or attributes that are specific to trouble administration. Contact information comprised of Name, Telephone, AddressLocation, etc…

The tmlX790.xsd uses elements that are defined in the tmlCommon namespace: tmlCom:Name, tmlCom:Telephone.

tmlTroubleReport.xml is an instance xml document that uses the elements from the namespace tmlX790 which is declared as the default namespace and the prefix tmlX790 is omitted. The elements Name, Telephone are very commonly used and maybe defined in various format. The naming conflicts can be by declaring the namespace in the xml document.

A8.2 EXAMPLE 2:

To be supplied

A8.3 EXAMPLE 3:

To be supplied

A9. tML Schema Examples (informative)

Capability

Description

or

Does the Item Support:

Support

Y/N/na

Values

allowed

Values supported

A14. Common Tags—Region n

End of tML Framework document

[1] There are several implementation framework standards in existence for telecommunications applications. One in particular, the Electronic Interactive Agent (the IA), supports XML message types. The IA is a regional and international standard (T1.xxx, Q.814). It is intended for use on the X interface. The IA standard specifies a means to transport EDI/EDIFACT, XML, and/or plain text messages over a TCP/IP‑based network environment utilizing Transport Layer Security (TLS).

[2] See the section on Vocabulary Standards for tag naming.

[3] A future means of handling this will be available when XML Schema is an approved standard and XML parsers emerge which can handle Schema notation.

[4] For more information, see the section on Namespaces.