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 ().
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.,
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
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:
schema
Pat Tap
Jeff Jones
XML
Consider this sample XML (obtained from the W3C Activity Statement on May 5, 2000):
Acme Pharmaceuticals Co.
7301 Smokey Boulevard
Smallville
Indiana
94571
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:
Abraham Lincoln
The White House
Gettysburg 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.
Example:
<- xml version="1.0"- >
Cheaper by the Dozen
Jane Doe
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:
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—
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 Tags—Region 1
A12. Common Tags—Region 2
A13. Common Tags—Region 3
A14. Common Tags—Region 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