Not official; see ftp://ftp.t1.org/pub/t1m1/new-t1m1.0/1m100020.doc

Committee T1 - Telecommunications
Standards Contribution
[T1M1/2001-003]

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

Tags

text structures (markup characters) that mark 
the beginning and end of elements within an 
XML document

telecommunications Markup Language 
(tML)


a meta-language based on XML that 
describes common vocabularies used in 
telecommunications OAM&P interface 
applications

tML Framework
a framework that guides development and 
implementation of extensions of XML and 
XML Schemas in the TMN context

tML Namespace


tML Schema
A schema that is registered in the tML 
repository. A tML schema may make 
reference to a schema in an external 
repository.

Unicode

a character coding system designed to 
support the interchange, processing, and 
display of the principal written languages of 
the Americas, Europe, the Middle East, 
Africa, India, Asia, and the Pacific Basin. 
Unicode provides a unique number for every 
character, regardless of the platform, the 
program, or the language. The most current 
version of the Unicode standard contains 
49,194 distinct coded characters. Unicode is 
a 16-bit superset of the ASCII character set. 
Unicode standards are synchronized with 
UCS-2 subset of ISO 10646.

Uniform Resource Identifier (URI)

the basic form of address on the Web. This 
includes URL (Uniform Resource Locators) 
and all future resource categories.  URLs are 
created using URI schemes, e.g., http:// and 
ftp:// are specific subsets of a URI.

Uniform Resource Locator (URL)

describes the location of Web resources; a 
hierarchical scheme consisting of  a protocol 
(e.g., http), followed by a hostname (e.g., 
www), and then a datapath

Uniform Resource Name (URN)
a name that identifies a resource or unit of 
information independent of its location. A 
URL identifies the location of a container for 
an instance of a resource identified by a 
URN.

Valid

an XML document with a declared schema 
that follows all the rules of that definition.  
An XML document cannot be valid unless it 
contains a <!DOCTYPE Declaration that 
declares a schema and also conforms to the 
schema declared.

Vocabulary (Telecommunications)
Collection of words (nouns, verbs) and 
meanings within the construct of a given 
telecommunications context.  Note: tag 
names are representations of (derived from) 
specific vocabulary words.

Well-formed

an XML document that follows all the rules 
of the XML specification but is not 
necessarily valid according to an associated 
schema.

World Wide Web Consortium (W3C) 
Recommendation
reflects consensus within W3C that the ideas 
or technology specified by a 
Recommendation are appropriate for 
widespread deployment and promote W3C's 
mission

XLink
defines constructs that may be inserted into 
XML schemas and XML documents to 
describe links between objects; uses XML 
syntax to create structures that can describe 
the simple unidirectional hyperlinks of 
today's HTML as well as more sophisticated 
links

XML aware
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.

XML processor
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.

XML Query Language (XQL)

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. 

XPointer
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: 
ebXMLelectronic business XML
TATrouble Administration
PICPrimary Inter-exchange Carrier
EAOElectronic Access Ordering
LOPOLocal 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.


A6.4	How this Framework will be used
- 	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

A6.6	tML in Context of a Complete Trading Partner Specification
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 DefinitionsThe 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 VocabularyThe 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 .  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.



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




A7.0	Generic Rules and Objectives

A7.1	Schemas
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  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. 

A7.2	Namespaces
****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

A7.3	Vocabulary Standards
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="c1"> <name>Pat Tap</name> </composer> 
<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>
<!-- Country is used as an attribute in the line below --> 
		<address country="US"
			<street>7301 Smokey Boulevard</street>
			<city>Smallville</city>
			<state>Indiana</state>
			<postal>94571</postal>
		</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.  

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> <!-- not allowed -->


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. 
Example:
<- xml version="1.0"- > 
<story:books xmlns:EInvtryBook='uri:E.Inventory.Book.x100/01' 
xmlns:EInvtryAuth='uri:E.Inventory.Author.x200/01'>                       
<!-- two namespace prefixes are available -->
<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. 


A7.4	Conformance


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).

Item
Capability
Description
 or
Does the Item 
Support:
Ref.
Status*
Support
Y/N/na
Values 
allowed
Values 
supported
1






2













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

where:

Itemthe number of the line item under consideration
Capability Description or Does the Item Support
Ref.
Status
Support Y/N/na
Values Allowed
Values Supported

A7.5	Repositories

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

Rules needed for the following:
- 	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 


A7.6	Registries

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).


A7.7	Semantics

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.


A7.8	UML Modeling

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.







A7.9	Core tML data types


Rule 18.	



A7.10	Security


Rule 19.	






A8	tML Namespace Examples (informative)


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)

A10.	tML document Examples (informative) 


A11.	Common TagsRegion 1

A12.	Common TagsRegion 2

A13.	Common TagsRegion 3

A14.	Common TagsRegion n




End of tML Framework document
  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). 

  See the section on Vocabulary Standards for tag naming.
  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.
  For more information, see the section on Namespaces.


25

		T1M1/2001-003
