OTA Tag name rules

[Scott Hinkelman/Austin/IBM <srh@us.ibm.com>]

ebXML Architects,
As an example,
the following are clips from the OTA spec 1, which can be found at
http://www.opentravel.org/, that specify the base naming rules for
the XML Travel Industry specifications.

--------------
OpenTravel Alliance, Customer Profile Specifications Page 14
Copyright © 2000. OpenTravel Alliance www.opentravel.org/
OTA version 1 messages MUST meet the requirements of well-formed XML
documents, as specified
in XML Recommendation 1.0, published by the W3C. The document is available
from the W3C
online at http://www.w3.org/TR/1998/REC-xml-19980210 .
OTA version 1 messages SHOULD begin with the XML declaration indicating use
of XML version
1.0. That declaration reads:
<?xml version ="1.0"?>
Valid OTA version 1 messages meet the grammar rules specified in the
document type definitions or
DTDs. Valid messages MUST include the document type declaration that
follows the XML
declaration. An example of a document type declaration is:
<!DOCTYPE OTA_v1 SYSTEM "OTA_v1.dtd">
Both the XML and document type declarations precede the OTA root element.

.......................................

3.3.3 Tag naming conventions
A key part of the XML grammar is consistent naming conventions for tags
that represent the
infrastructure and business-related elements. Tag name writers MUST follow
these rules unless
business requirements require other naming conventions.

OpenTravel Alliance, Customer Profile Specifications Page 15
Copyright © 2000. OpenTravel Alliance www.opentravel.org/
· Use mixed case tag names, with the leading character of each word in
upper case and the
remainder in lower case.
Example: <v1.Cust.PaymentForm>
· Acronyms are discouraged, but where needed, use all upper case.
Example: <v1.Cust.URL>
· Where acronyms or single-letter words cause two upper case characters to
be adjacent, separate
them with an underscore ( _ ) .
Example: <v1.Addr.PO_Box>
· Prefixes will use a period (.) as a separator.
Example: <v1.Cust.Pay.CreditCard>
OTA's tag naming conventions include the specification version and content
hierarchy as prefixes
and, as a result, will require greater bandwidth to transmit than tags with
more cryptic codes. OTA
made the decision to include this much text in the tags ? a decision that
went through lengthy debate
and several reviews ? so OTA could convert the data model to XML-Schema as
easily as possible.
XML-Schema will not need the context or hierarchy included in the tag
names, which will reduce
their size.
The longer tag names also make the tags human-readable, an advantage over
traditional EDI coding
that requires machine interpretation of even simple transactions or
messages. With OTA's tags,
parties can read the messages directly to see their content, which will
make them accessible to many
more trading partners than before, using no more than an XML-enabled Web
browser. Also, in North
America at least, bandwidth for transmitting messages is becoming more
available and less
expensive.

3.3.4 Tag naming guidelines
Tag writers SHOULD use these guidelines as good practices when constructing
tag names.
· Use the same tag names with elements in a similar child structure
· Use plural tag names only for collections.
· Keep element and attribute names to 25 characters.
However, prefixes for use in DTDs do not count in the calculation. With
XML-Schema, the context
for tags will provide much of the meaning and help keep tag names short.

--------------------------

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074