XML DTD Elements and Attributes

It is important to note that XML is case sensitive. Therefore, all elements and attributes in documents based on this DTD must match the case as indicated herein.

All documents based on the TeleMessage DTD shall begin as follows:

 

Notes:

  

XML References

A reference allows you to include additional text or markup in an XML document.

References always begin with the character “&” (which is specially reserved) and end with the character “;”.

XML has two kinds of references:

 

ENTITY REFERENCES

An entity reference, like “&”, contains a name (in this case, “amp”) between the start and end delimiters. The name refers to a predefined string of text and/or markup, like a macro in the C or C++ programming languages.

 

CHARACTER REFERENCES

A character references, like “&”, contains a hash mark (“#”) followed by a number. The number always refers to the Unicode code for a single character, such as 65 for the

letter “A” or 233 for the letter “י”, or 8211 for an en-dash. For advanced uses, XML provides a mechanism for declaring your own entities, but that is outside the scope of this document. XML also provides five pre-declared entities that you can use to escape special characters in an XML document:

For example, the corporate name “AT&T” should appear in the XML markup as “AT&T”: the XML parser will take care of changing “&” back to “&” automatically when the document is processed. You must use character references for greek and other extended characters.

Character

Predeclared Entity

&

&

<

>

"

'

 

ELLIPSIS

The ellipsis (…) in the code samples below indicate missing data. This data will vary from case to case and the correct value must be determined at the time of implementation

 

 

 

 


TELEMESSAGE 

TELEMESSAGE is the root element of any document based on this DTD. It is used to transmit the message content (for messages to be delivered to a recipient) and other

related information between TeleMessage and partner’s system.

TELEMESSAGE is a wrapper element that will hold all other elements in this document.

DTD Fragment

<!ELEMENT TELEMESSAGE (TELEMESSAGE_CONTENT+ , VERSION)>

Structure

TELEMESSAGE is allowed the following markup:

  • One TELEMESSAGE_CONTENT (from partner to TeleMessage) elements

AND

  • One VERSION element

 

Attributes

None

 

Example

See Send a message sample


TELEMESSAGE_CONTENT

TELEMESSAGE_CONTENT contains one of the basic actions that can be transmitted in this XML.

 

DTD Fragment

<!ELEMENT TELEMESSAGE (MESSAGE+ | RESPONSE+ | MESSAGE_STATUS_QUERY | MESSAGE_STATUS+)>

 

Structure

TELEMESSAGE_CONTENT is allowed the following markup:

  • One or More MESSAGE (from partner to TeleMessage) elements

OR

  • One or More RESPONSE (from TeleMessage to partner) element

OR

  • One MESSAGE_STATUS_QUERY (from partner to TeleMessage) element

OR

  • One or More MESSAGE_STATUS (from TeleMessage to partner) elements

 

Attributes

None

 

Example

See Send a message sample


MESSAGE

MESSAGE is a wrapper element used to contain all the data that the partner delivers to the TeleMessage system. This includes destination information, message content, and the sent date among other information.

 

DTD Fragment

<!ELEMENT MESSAGE (MESSAGE_INFORMATION, OWNER?, USER_FROM, CALLBACK_PREFERENCES?, MESSAGE_CONTENT?, USER_TO?, USER_CC?, USER_BCC?,>

 

Structure

MESSAGE may appear one or more times in TELEMESSAGE, as long as RESPONSE, MESSAGE_STATUS_QUERY or MESSAGE_STATUS do not also appear. MESSAGE is allowed the following markup (note: Elements must appear in the order listed below):

  • One MESSAGE_INFORMATION element
  • Zero or One OWNER element
  • One USER_FROM
  • Zero or One CALLBACK_PREFERENCES element
  • Zero or One MESSAGE_CONTENT element
  • Zero or One USER_TO element
  • Zero or One USER_CC element
  • Zero or One USER_BCC element

 

Attributes

None

 

Example

Note: ellipsis (…) has been used to indicate omitted data/content/markup.


MESSAGE_INFORMATION

MESSAGE_INFORMATION is a wrapper element used to contain any other information beside the message content. The data will include the locale (language) for the phone/web menus, subject, date/time the message was sent and the date for scheduling a postponed delivery of a message (“scheduled message”).

 

DTD Fragment

<!ELEMENT MESSAGE_INFORMATION (LOCALE?, SUBJECT?, TIME_STAMP, SCHEDULE_TO?)>

 

Structure

MESSAGE_INFORMATION is the first element allowed in MESSAGE and must appear one time only, immediately following the open tag.

MESSAGE_INFORMATION is allowed the following markup (note: Elements must appear in the order listed below):

  • Zero or One LOCALE element
  • Zero or One SUBJECT element
  • One TIME_STAMP element
  • Zero or one SCHEDULE_TO element

Attributes

None

 

Example

Note: ellipsis (…) has been used to indicate omitted data/content/markup.

 


OWNER

OWNER is a wrapper element used to contain the entire data specific to each message owner user. OWNER will include one CIML (Customer Identity Markup Language) element in case the owner is the partner customer or one PARTNER_INFORMATION element in case the owner is the partner himself. The data will be used as the message “Owner” in relation to its billing respects and other preferences. Note: The OWNER element should only be used for billing purposes as an option to charge the message on a different user then the USER_FROM. Messages which are sent using the OWNER element will not appear in the sender Inbox folder in the Web GUI, and the replies to them will not be sent to the sender reply devices. In order to be able to track messages and get the replies to them a USER_FROM element should be used.

 

DTD Fragment

<!ELEMENT OWNER (CIML | PARTNER_INFORMATION)>

 

Structure

OWNER is required to appear once in the MESSAGE element, immediately following

close tag.

OWNER is allowed the following markup:

  • Zero or One CIML element
  • Zero or One PARTNER_INFORMATION element

 

Attributes

None

 

Example

Note: ellipsis (…) has been used to indicate omitted data/content/markup.


USER_FROM

USER_FROM is a wrapper element used to contain the entire data specific to each message originator. USER_FROM will include one CIML (Customer Identity Markup Language) element in case the originator is the partner customer or one PARTNER_INFORMATION element in case the originator is the partner himself. The data will be used as the message “Sender” in all devices that receives the message.

 

DTD Fragment

<!ELEMENT USER_FROM (CIML | PARTNER_INFORMATION)>

 

Structure

USER_FROM is required to appear once in the MESSAGE element, following either

(if included) or close tag.

USER_FROM is allowed the following markup:

  • Zero or One CIML element
  • Zero or One PARTNER_INFORMATION element

 

Attributes

None

 

 

Example

Note: ellipsis (…) has been used to indicate omitted data/content/markup.


CALLBACK_PREFERENCES

CALLBACK_PREFERENCES is a wrapper element used to contain the entire data specific to each message callback preference. CALLBACK_PREFERENCES defines “reply to” device.

DTD Fragment

<!ELEMENT CALLBACK_PREFERENCES (#PCDATA)>

Structure

 CALLBACK_PREFERENCES is an optional element and may appear zero  or one times in the MESSAGE.   

 CALLBACK_PREFERENCES is allowed the following markup:

  • 1 – Reply to email
  • 2 – Reply to mobile

Attributes

None

 

Example

< CALLBACK_PREFERENCES>1


MESSAGE_CONTENT

MESSAGE_CONTENT is a wrapper element used to contain the actual body of the message(s) that is to be sent to the receiver of the message(s).

 

DTD Fragment

<!ELEMENT MESSAGE_CONTENT (TEXT_MESSAGE*, PROPERTY_MESSAGE*, FILE_MESSAGE*)>

 

Structure

MESSAGE_CONTENT is an optional element and may appear zero1 or one times in the MESSAGE element. MESSAGE_CONTENT is allowed the following markup:

  • Zero or More TEXT_MESSAGE elements
  • Zero or More PROPERTY _MESSAGE elements
  • Zero or More FILE _MESSAGE elements

 

Attributes

None

 

Example

Note: ellipsis (…) has been used to indicate omitted data/content/markup.

The message goes here.

1 As long as SUBJECT element is included in MESSAGE_INFORMATION


USER_TO

USER_TO is a wrapper element used to contain the entire data specific to each message recipient. USER_TO will include one or more CIML (Customer Identity Markup Language) elements. The data will include the type of the device and the number/address the message should be sent to, along other recipient info.

 

DTD Fragment

<!ELEMENT USER_TO (CIML +)>

 

Structure

USER_ TO is an optional element and may appear zero2 or one times in the MESSAGE element, following either (if included) or close tag. USER_TO is allowed the following markup:

  • One or More CIML element

 

Attributes

None

 

Example

Note: ellipsis (…) has been used to indicate omitted data/content/markup.

………


USER_CC

USER_CC is a wrapper element used to contain the entire data particular to each CC (Carbon Copy) message recipient. USER_CC will include one or more CIML (customer identity) elements. The data will include the type of device and the number/address the message should be sent to, along other recipient info.

 

DTD Fragment

<!ELEMENT USER_CC (CIML+)>

 

Structure

USER_CC is an optional element and may appear zero or one times in the MESSAGE element, following either (if included) or close tag. USER_CC is allowed the following markup:

  • One or More CIML element

2 As long as USER_CC or USER_BCC element is included in MESSAGE

Attributes

None

 

Example

Note: ellipsis (…) has been used to indicate omitted data/content/markup.

………

 


USER_BCC

USER_BCC is a wrapper element used to contain the entire data particular to each BCC (Blind Carbon Copy) message recipient. USER_BCC will include one or more CIML (customer identity) elements. The data will include the type of device and the number/address the message should be sent to, along other recipient info.

 

DTD Fragment

<!ELEMENT USER_BCC (CIML+)>

 

Structure

USER_BCC is an optional element and may appear zero or one times in the MESSAGE element, following either , or close tag. USER_BCC is allowed the following markup:

  • One or More CIML element

 

Attributes

None

 

Example

Note: ellipsis (…) has been used to indicate omitted data/content/markup.

………


LOCALE

LOCALE is a wrapper element used to hold the specific language to be used in the message sent. If provided, it must include the following elements: LOCAL_LANGUAGE_ID and LOCALE_COUNTRY_ID. The default language to be used in this field is US English.

 

DTD Fragment

<!ELEMENT LOCALE (LOCALE_LANGUAGE_ID, LOCALE_COUNTRY_ID)>

 

Structure

LOCALE may appear one time only in the MESSAGE_INFORMATION, immediately following the open tag. See “MESSAGE_INFORMATION” in this document for a complete description of the structure of that element.

LOCALE is allowed the following markup (note: Elements must appear in the order listed below):

  • One LOCALE_LANGUAGE_ID element
  • One LOCALE_COUNTRY_ID element

 

Attributes

None

 

Example

Note: ellipsis (…) has been used to indicate omitted data/content/markup.


SUBJECT

SUBJECT contains the text to enter in the “subject” field in the end devices.

 

DTD Fragment

<!ELEMENT SUBJECT (#PCDATA)>

 

Structure

SUBJECT may appear zero3 or one times as part of the MESSAGE_INFORMATION element, following either close tag or open tag.

See “MESSAGE_INFORMATION” in this document for complete description of the structure of that element.

The content of SUBJECT is Parsable Character Data (PCDATA). No markup is allowed. The SUBJECT has to be alphanumeric with no special punctuation4. The maximum length of the SUBJECT element is 960 characters (including spaces. In languages other than English this size maybe smaller). The SUBJECT of Messaging requests with SUBJECT longer than 960 characters will be trimmed.

 

 

Attributes

None

 

Example

…Welcome to TeleMessage !!!…

3 As long as MESSAGE_CONTENT, with at least one TEXT_MESSAGE, is included in MESSAGE

4 For example, ~, ^, _ | \, [], {}, “, ‘ &, and %


TIME_STAMP

TIME_STAMP indicates the time the message was sent (or was delivered to the TeleMessage system (by another party)). It is used in the MESSAGE element. TIME_STAMP identifies the date/time the originator sent the message. This value is only used for logging/reporting purposes.

The content of the tags should conform to the following format: yyyymmdd hh:mm:ss

Hours must be expressed in Military hours, with a leading zero.

Please not that the time zone is GMT+0.

 

DTD Fragment

<!ELEMENT TIME_STAMP (#PCDATA)>

 

Structure

TIME_STAMP is required to appear once in the MESSAGE_INFORMATION element, following , close tag, or open tag. The content of TIME_STAMP is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

…19990603 01:36:45…


SCHEDULE_TO

SCHEDULE_TO is used for scheduling a message to a later time for a postponed message delivery. This is to give the message originator the ability to send messages at different delayed seconds/minutes/hours/days/months/years for many different purposes (e.g. different time zones in the world).

The content of the tag should conform to the following format: yyyymmdd hh:mm:ss

Hours must be expressed in Military hours, with a leading zero.

Please not that the time zone is GMT+0.

 

DTD Fragment

<!ELEMENT SCHEDULE_TO (#PCDATA)>

 

Structure

SCHEDULE_TO may appear zero or one times in MESSAGE_INFORMATION, following close tag. See “MESSAGE_INFORMATION” in this document for a complete description of the structure of that element.

The content of SCHEDULE_TO is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

…20010101 18:30:00…


 

CIML

CIML (Customer Identity Markup Language) is a wrapper element used to contain all data particular to each message originator/recipient. It is used in the MESSAGE (indicate the message originator), USER_TO, USER_CC and USER_BCC elements.

 

DTD Fragment

<!ELEMENT CIML (NAML , device_information+)>

 

Structure

The CIML must appear one time only in the USER_FROM element (as long as PARTNER_INFORMATION do not also appear) immediately following open tag. The same element is used also in the USER_TO, USER_CC, USER_BCC elements.

The CIML is allowed the following markup (note: Elements must appear in the order listed below):

  • One NAML element
  • One or More device_information elements

 

Note: If the CIML appear in the USER_FROM element and contains device_information element with device_type =”SMS”, the device value will be used as a sender number in the SMS message.

 

Attributes

None

 


 

DEVICE_INFORMATION

DEVICE_INFORMATION is a wrapper element used to contain a recipient device data, this information could include a recipient phone number, email address etc.

 

DTD Fragment

<!ELEMENT DEVICE_INFORMATION (DEVICE_TYPE, DEVICE_VALUE, DEVICE_DESCRIPTION?)>

 

Structure

DEVICE_INFORMATION must appear one or more times in CIML element, immediately following the close tag.

DEVICE_INFORMATION is allowed the following markup (note: Elements must appear in the order listed below):

  • One DEVICE_TYPE element
  • One DEVICE_VALUE element
  • Zero or One DEVICE_DESCRIPTION element

 

Attributes

None.

 

Example

 


 

DEVICE_TYPE

DEVICE_TYPE indicates the device type for sending a message to. There are several predefined attribute values, as follows:

  • HomeNumber
  • BusinessNumber
  • BusinessFax
  • MMS
  • MobileNumber
  • SMS
  • EmailAddress

*TeleMessage will add additional supported devices from time to time

DTD Fragment

<!ELEMENT DEVICE_TYPE EMPTY>

<!ATTLIST DEVICE_TYPE

DEVICE_TYPE (HomeNumber | BusinessNumber | BusinessFax | MMS | MobileNumber | SMS | EmailAddress) #REQUIRED>

 

Structure

DEVICE_TYPE must appear one time in a DEVICE_INFORMATION element, immediately following the open tag. DEVICE_TYPE is an empty element, so it doesn’t require a close tag or content. Empty tags must have a “/” before the close delimiter “>”.

 

Attributes

DEVICE_TYPE is the only attribute on DEVICE_TYPE. It is required, and has several set values, as described above. There is no default value, so the attribute must be defined each time DEVICE_TYPE occurs in a document.

 

Example

 

OR

 


 

DEVICE_VALUE

DEVICE_VALUE is used to indicate a device value (like email address, phone number etc.).

 

DTD Fragment

<!ELEMENT DEVICE_VALUE (#PCDATA)>

 

Structure

DEVICE_VALUE must appear one time in a DEVICE_INFORMATION element, immediately following the close tag.

The content of DEVICE_VALUE is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

Arthur@telemessage.com


DEVICE_DESCRIPTION

DEVICE_DESCRIPTION is used to indicate a device description other then the declared type. For example mobile description could be “Cellular Phone”.

DTD Fragment

<!ELEMENT DEVICE_DESCRIPTION (#PCDATA)>

 

Structure

DEVICE_ DESCRIPTION may appear zero or one time in a DEVICE_INFORMATION element, immediately following the close tag.

The content of DEVICE_ DESCRIPTION is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

CELLULAR


PARTNER_INFORMATION

PARTNER_INFORMATION is a wrapper element used to contain all data particular to each message originator for a specific client (or customer) of TeleMessage (i.e. a partner company). This element allows the TeleMessage system to recognize and bill the correct originator company/client of TeleMessage. This information is pre-defined by a TeleMessage account manager and so is also constant for each partner/client.

 

DTD Fragment

<!ELEMENT PARTNER_INFORMATION (COMPANY_NAME, COMPANY_ID, COMPANY_PASSWORD?)>

 

Structure

PARTNER_INFORMATION must appear one time only in the USER_FROM (as long as ciml_record do not also appear) immediately following open tag. PARTNER_INFORMATION is allowed the following markup (note: Elements must appear in the order listed below):

  • One COMPANY_NAME element
  • One COMPANY_ID element
  • Zero or One COMPANY_PASSWORD element

 

Attributes

None

 

Example

Note: ellipsis (…) has been used to indicate omitted data/content/markup.


TEXT_MESSAGE

 

TEXT_MESSAGE contains the actual content of the message that is to be sent to the end user receiver.

 

DTD Fragment

<!ELEMENT TEXT_MESSAGE (MESSAGE_INDEX, TEXT)>

 

Structure

TEXT_MESSAGE may appear zero or more times in MESSAGE_CONTENT element. See “MESSAGE_CONTENT” in this document for complete description of the structure of that element.

The content of TEXT_MESSAGE is TEXT element, which is a Parsable Character Data (PCDATA). No markup is allowed. The TEXT_MESSAGE has to be alphanumeric with no special punctuation5. The maximum length of the TEXT_MESSAGE element is 4000 characters including spaces. Messaging requests with TEXT_MESSAGE longer than 4000 characters will be rejected with an error status response (see Error & status codes).

 

Attributes

None

 

Example

0

This is a text message!


PROPERTY_MESSAGE

PROPERTY_MESSAGE contains a property and its value. This is predominantly used for special messages for different clients of TeleMessage. It is handled differently for each client. e.g. if the customer has prerecorded sentences with different call flows, and he wants to send a specific message according to a specific call flow.

DTD Fragment

<!ELEMENT PROPERTY_MESSAGE (MESSAGE_INDEX, PROPERTY_NAME, PROPERTY_VALUE)>

 

Structure

PROPERTY_MESSAGE may appear zero or more times in MESSAGE_CONTENT element.

 

For example, ~, ^, _ | \, [], {}, “, ‘ &, and %

Attributes

None

 

Example

 

2

INTERACTIVE

true

 


PROPERTY_NAME

PROPERTY_NAME is the name of the property. This is a predefined value that will be provided by a TeleMessage account manager.

 

DTD Fragment

<!ELEMENT PROPERTY_NAME (#PCDATA)>

 

Structure

PROPERTY_NAME must appear once in PROPERTY_MESSAGE element.

 

Attributes

None

 

Example

INTERACTIVE


PROPERTY_VALUE

PROPERTY_VALUE is the value of a property (See PROPERTY_MESSAGE for more information)

 

DTD Fragment

<!ELEMENT PROPERTY_VALUE (#PCDATA)>

 

Structure

PROPERTY_VALUE must appear once in PROPERTY_MESSAGE element.

 

Attributes

None

 

Example

true


 

FILE_MESSAGE

 

FILE_MESSAGE is used to attach a file to a message. The FILE_MESSAGE element includes sub-elements that deliver the following information: The name of the file as the end-user will see, the file data (content) and the file type. See the FILE_NAME, MIME_TYPE and FILE_DATA elements for more information.

 

DTD Fragment

<!ELEMENT FILE_MESSAGE (MESSAGE_INDEX, FILE_NAME, MIME_TYPE?, FILE_DATA)>

 

Structure

FILE_MESSAGE may appear zero or more times in MESSAGE_CONTENT element.

 

Note:  In order to send MMS as slide show, insert SMIL (according to http://www.ietf.org/rfc/rfc4536.txt) as file attachment (Use application/smil mime type) else if you use regular file attachment default SMIL will be created.  Important to define recipient type MMS (see section YYY. Type).

 

Attributes

None

 

Example

 

1

truste.gif

image/gif

 

http://www.telemessage.com/images/homepage/hp_truste.gif

 

 


 

FILE_NAME

FILE_NAME contains the name of the file that will be presented to the end user (only the name itself , without the full path to the file).

 

DTD Fragment

<!ELEMENT FILE_NAME (#PCDATA)>

 

Structure

FILE_NAME must appear one time in FILE_MESSAGE element.

 

Attributes

None

 

Example

Special_Message.wav


 

MIME_TYPE

MIME_TYPE contains the mime type of the file. If absent the mime type is automatically determined according to the file name extension (for common file types). See http://www.iana.org/assignments/media-types/ for the list of registered mime types.

 

DTD Fragment

<!ELEMENT MIME_TYPE (#PCDATA)>

 

Structure

MIME_TYPE may appear zero or one time in FILE_MESSAGE element.

 

Note:  In order to send MMS use application/smil mime type.

 

Attributes

None

 

Example

text/html


FILE_DATA

FILE_DATA contains the content of the file to be attached, either as an http URL from which the actual file will be retrieved, a base64 encoded file, or a raw file. Exactly one of these must appear within a FILE_DATA element. See the FILE_REFERENCE, FILE_DATA_BASE64 and FILE_DATA_RAW elements for details.

 

DTD Fragment

<!ELEMENT FILE_DATA (FILE_REFERENCE | FILE_DATA_BASE64 | FILE_DATA_RAW)>

 

Structure

FILE_DATA must appear one time in FILE_MESSAGE element.

 

Attributes

None

 

Example

 

AB4D2DGLG542FF…

 


FILE_DATA_BASE64

FILE_DATA_BASE64 is a file encoded using the Base64 encoding format. The actual file content is provided here in the Base64 format. More information on Base64 can be obtained from http://www.ietf.org/rfc/rfc1521.txt

DTD Fragment

<!ELEMENT FILE_DATA_BASE64 (#PCDATA)>

 

Structure

FILE_DATA_BASE64 may appear zero or one time in FILE_DATA element.

 

Attributes

None

 

Example

 

AB4D2DGLG542FF…

 


 

FILE_DATA_RAW

FILE_DATA_RAW is a file whose content is specified directly within this element. Often a CDATA XML tag is useful here so that XML reserved characters such as ‘<’ and ‘>’ can appear within the file content without causing parse errors.

 

DTD Fragment

<!ELEMENT FILE_DATA_RAW (#PCDATA)>

Structure

FILE_DATA_RAW may appear zero or one time in FILE_DATA element.

 

Example

 

 

 


 

LOCALE_LANGUAGE_ID

LOCALE_LANGUAGE_ID is used to choose the language, which will be used by the system through the different messaging devices: Telephony, email, SMS, MMS and fax. For example in the telephony it will be to choose the TTS (Text To Speech) engines to read the message to telephone devices. In emails it will be used to choose the correct language for the words: “subject”, ”to”, “from” etc. If the field is empty the default is English. (e.g. EN – English). TeleMessage is in the process of adding more languages continuously. If you need to use a specific language you must check if the language is supported by TeleMessage (to do so please consult your account manager).

 

DTD Fragment

<!ELEMENT LOCALE_LANGUAGE_ID (#PCDATA)>

 

Structure

LOCALE_LANGUAGE_ID is required to appear once in the LOCALE, immediately following open tag. See “LOCALE” in this document for complete description of the structure of that element. The content of LOCALE_LANGUAGE_ID is Parsable Character Data (PCDATA) but should be based upon ISO-639 Language Code. No markup is allowed.

 

Attributes

None

 

Example

…EN…


LOCALE_COUNTRY_ID

LOCALE_COUNTRY_ID is used to indicate the country (to distinguish between different pronunciations) which will be used by TTS engines to read the message to telephone devices (e.g. Great Britain or US English).

 

DTD Fragment

<!ELEMENT LOCALE_COUNTRY_ID (#PCDATA)>

Structure

LOCALE_COUNTRY_ID is required to appear once in the LOCALE, immediately following close tag. See “LOCALE” in this document for complete description of the structure of that element.

The content of LOCALE_COUNTRY_ID is Parsable Character Data (PCDATA) but should be based upon ISO-3166 Country Codes. No markup is allowed.

 

Attributes

None

 

Example

…US…


 

COMPANY_NAME

COMPANY_NAME is used to indicate the name of the partner. Messages may be initiated by the partner them self, or via a customer who sends the message to the partner, who passes the message on to the TeleMessage system. If this element is provided then the “Sender” of the message will be the COMPANY_NAME.

 

DTD Fragment

<!ELEMENT COMPANY_NAME (#PCDATA)>

 

Structure

COMPANY_NAME is the first element allowed in PARTNER_INFORMATION and must appear one time only, immediately following open tag.

See “PARTNER_INFORMATION” in this document for complete description of the structure of that element. The content of COMPANY_NAME is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

…NTT DoCoMo…


COMPANY_ID

COMPANY_ID is used to authenticate the partner. Each partner is assigned a unique COMPANY_ID. The TeleMessage Data Base creates the unique COMPANY_ID value for the partner. Please contact your account manager to get your COMPANY_ID.

 

DTD Fragment

<!ELEMENT COMPANY_ID (#PCDATA)>

Structure

COMPANY_ID is required to appear once in the PARTNER_INFORMATION, immediately following close tag. See “PARTNER_INFORMATION” in this document for complete description of the structure of that element.

The content of COMPANY_ID is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

…245…


COMPANY_PASSWORD

COMPANY_PASSWORD is used to authenticate the partner. Each partner is assigned a COMPANY_PASSWORD. Please contact your account manager to get your COMPANY_PASSWORD or change it.

 

DTD Fragment

<!ELEMENT COMPANY_PASSWORD (#PCDATA)>

 

Structure

COMPANY_PASSWORD is required to appear once in the PARTNER_INFORMATION, immediately following close tag. See “PARTNER_INFORMATION” in this document for complete description of the structure of that element.

The content of COMPANY_PASSWORD is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

…HY7F3FGS…


MESSAGE_INDEX

MESSAGE_INDEX specifies the location of the message. A message is composed out of several elements, which their order may be of different importance to be played/viewed for the end user. The following elements must include the MESSAGE_INDEX element when provided: FILE_MESSAGE, TEXT_MESSAGE or PROPERTY_MESSAGE. The value 0 is the first message, 1 is the second, and so on.

 

Important:

(1) The MESSAGE_INDEX value must be unique in every different MESSAGE_INDEX element in the XML file.

(2) The messages indexes must be sequential and begin from zero.

 

DTD Fragment

<!ELEMENT MESSAGE_INDEX (#PCDATA)>

 

Structure

MESSAGE_INDEX is the first element allowed in TEXT_MESSAGE, PROPERTY_MESSAGE and FILE_MESSAGE. MESSAGE_INDEX must appear one time only, immediately following the , and open tag.

The content of MESSAGE_INDEX is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

 

1

This is the second part of the message/TEXT>

 

 

0

This is the first part of the text message.

 

The above XML example will render to the following sentence for the end user:

“This is the first part of the text message. This is the second part of the message.”


RESPONSE

RESPONSE is a wrapper element used to acknowledge a received message by the TeleMessage system. The response can be of 2 kinds: a successfully received message will produce a RESPONSE, which includes the MESSAGE_ID and MESSAGE_KEY. An

unsuccessful received message will produce a RESPONSE, which includes an error REPONSE_STATUS and RESPONSE_STATUS_DESC (see Error & Status Codes). RESPONSE describes the status of the message after TeleMessage has received it from the partner (and before it has been sent out to the end user receiver). To receive the status of the message delivery, a partner must initiate a MESSAGE_STATUS_QUERY request.

 

DTD Fragment

<!ELEMENT RESPONSE (MESSAGE_ID?, MESSAGE_KEY?, RESPONSE_STATUS, RESPONSE_STATUS_DESC?)>

 

Structure

RESPONSE may appear one time or more in TELEMESSAGE, as long as MESSAGE, MESSAGE_STATUS_QUERY, or MESSAGE_STATUS do not also appear.

RESPONSE is allowed the following markup (note: Elements must appear in the order listed below):

One or more of the following set:

  • Zero or One MESSAGE_ID element
  • Zero or One MESSAGE_KEY element
  • One RESPONSE_STATUS element
  • Zero or One RESPONSE_STATUS_DESC element

 

 

Attributes

None

 

Example

<RESPONSE_STATUS…/>


MESSAGE_ID

MESSAGE_ID contains the value of a unique identifier for each message in the TeleMessage system. It is used to track messages throughout the system. Therefore, the MESSAGE_ID has to be unique for each message throughout the lifetime of the application, except in the case when the previous delivery attempt of the message fails.

TeleMessage’s Data Base will generate the identifier after each valid MESSAGE sent, and may be used in any RESPONSE, MESSAGE_STATUS_QUERY or MESSAGE_STATUS documents that are relevant to that particular message, as long as the documents are parsed properly.

 

DTD Fragment

<!ELEMENT MESSAGE_ID (#PCDATA)>

 

Structure

MESSAGE_ID appears in RESPONSE, MESSAGE_STATUS and MESSAGE_STATUS_QUERY. It is the first element in RESPONSE, but may appear zero or one times depending if the MESSAGE document returns a successful status (see see Error & Status Codes). In MESSAGE_STATUS it is the first element and is allowed once. In MESSAGE_STATUS_QUERY it is the only element and must appear one or more times.

The content of MESSAGE_ID is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

77777


 

MESSAGE_KEY

MESSAGE_KEY is the unique key of a message in the TeleMessage system. The key is used for security reasons to acquire the information about the message. This is similar to having a “Password” accompanying a “User ID” to secure the entrance to the system.

The TeleMessage Data Base generates the MESSAGE_KEY data randomly.

 

DTD Fragment

<!ELEMENT MESSAGE_ KEY (#PCDATA)>

 

 

Structure

MESSAGE_KEY appears in RESPONSE and MESSAGE_STATUS_QUERY immediately following the close tag.

 

Attributes

None

 

Example

10021016319846572323417266385885


 

SHOW_REPLIES

SHOW_REPLIES is a Boolean key. The key is used for indicating if to show the text replies of a message.

 

DTD Fragment

<!ELEMENT SHOW_REPLIES (#PCDATA)>

 

 

Structure

 SHOW_REPLIES appears in MESSAGE_STATUS_QUERY immediately following the close tag. The valid values are true / false.

The default value is false.

 

Attributes

None

 

Example

< SHOW_REPLIES >true


RESPONSE_STATUS

RESPONSE_STATUS indicates whether the message was accepted by TeleMessage’s system or not (see Error & Status Codes for possible values).

 

DTD Fragment

<!ELEMENT RESPONSE_STATUS (#PCDATA)>

 

Structure

RESPONSE_STATUS must appear one time only in a RESPONSE element (it will appear multiple times if the set is repeated – see RESPONSE for more detail) immediately following close tag.

 

Attributes

None.

 

Example

…100


RESPONSE_STATUS_DESC

RESPONSE_STATUS_DESC (Response Status Description) is used to describe the status. This is the verbal description of the RESPONSE_STATUS data (which is a number). The content of the text in tags is determined by the value of the RESPONSE_STATUS element. This element may not appear if the received message status is a successful one.

 

DTD Fragment

<!ELEMENT RESPONSE_STATUS_DESC (#PCDATA)>

Structure

RESPONSE_STATUS_DESC may appear zero or one times in a RESPONSE element, immediately following the RESPONSE_STATUS element.

The content of RESPONSE_STATUS_DESC is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

 

User does not exist in the system

 

OR

Invalid User Password


MESSAGE_STATUS_QUERY

MESSAGE_STATUS_QUERY is used to query the TeleMessage system about the status of a message delivery to message recipient. The query is based on Message ID values.

 

DTD Fragment

    <!ELEMENT MESSAGE_STATUS_QUERY (MESSAGE_ID+, MESSAGE_KEY+, SHOW_REPLIES)>

 

Structure

MESSAGE_STATUS_QUERY may appear one time only in TELEMESSAGE, as long as MESSAGE, RESPONSE, or MESSAGE_STATUS do not also appear.

MESSAGE_STATUS_QUERY is allowed the following markup:

  • One or More MESSAGE_ID elements
  • One or More MESSAGE_KEY elements

One or More SHOW_REPLIES elements

 

Attributes

None.

 

Example

12345

FA64KUR4E12345

344344

YAG4KRRVE344344


MESSAGE_STATUS

MESSAGE_STATUS is a wrapper element used to send a message to the partner indicating the status of the message after it has been sent from TeleMessage’s system to the recipient.

 

DTD Fragment

<!ELEMENT MESSAGE_STATUS (STATUS_ID, STATUS_DESCRIPTION, MESSAGE_ID, RECIPIENT_STATUS*)>

 

Structure

MESSAGE_STATUS may appear one time only in TELEMESSAGE, as long as MESSAGE, RESPONSE, or MESSAGE_STATUS_QUERY do not also appear MESSAGE_STATUS is allowed the following markup (note: Elements must appear in the order listed below):

  • One STATUS_ID element
  • One STATUS_DESCRIPTION element
  • One MESSAGE_ID element
  • Zero or More RECIPIENT_STATUS elements

 

Attributes

None.

 

Example


STATUS_ID

STATUS_ID is used to indicate a delivery status identifier being produced by TeleMessage system. See Query Status & Replies.

 

DTD Fragment

<!ELEMENT STATUS_ID (#PCDATA)>

 

Structure

STATUS_ID must appear one time only in a MESSAGE_STATUS element, immediately following the open tag.

The content of STATUS_ID is Parsable Character Data (PCDATA). No markup is allowed.

Attributes

None

 

Example

1000


STATUS_DESCRIPTION

STATUS_DESCRIPTION is used to indicate a description for each status.

 

DTD Fragment

<!ELEMENT STATUS_DESCRIPTION (#PCDATA)>

 

Structure

STATUS_ DESCRIPTION must appear one time only in a MESSAGE_STATUS element, immediately following the close tag.

The content of STATUS_ DESCRIPTION is Parsable Character Data (PCDATA). No markup is allowed.

 

Attributes

None

 

Example

Message delivered successfully


RECIPIENT_STATUS

RECIPIENT_STATUS element is a wrapper element used to describe recipient status according to device.

 

DTD Fragment

<!ELEMENT RECIPIENT_STATUS (RECIPIENT_NAME , DEVICE)>

 

Structure

RECIPIENT_STATUS may appear zero or More time in MESSAGE_STATUS. RECIPIENT_STATUS element allowed the following markup:

  • One RECIPIENT_NAME element
  • One DEVICE element

 

Attributes

None

Example

…< RECIPIENT_STATUS >

…..


RECIPIENT_NAME

RECIPIENT_NAME element is a wrapper element used to contain recipient name.

 

DTD Fragment

<!ELEMENT RECIPIENT_NAME (#PCDATA)>

 

Structure

RECIPIENT_ NAME has to appear one time in RECIPIENT_STATUS.

 

Attributes

None

Example


DEVICE

DEVICE is used to specify a message recipient device status (and answer to a question asked by the partner (can be sent originally from a partner’s customer). The question can be defined using the PROPERETY_MESSAGE element.

 

DTD Fragment

<!ELEMENT DEVICE (TYPE, VALUE, STATUS, DESCRIPTION, ANSWER?)>

 

Structure

DEVICE may appear one time in the RECIPIENT_STATUS. DEVICE is allowed the following markup (note: Elements must appear in the order listed below):

  • One TYPE element
  • One VALUE element
  • One STATUS element
  • One DESCRIPTION element
  • One STATUS_DATE element
  • One or zero ANSWER element

Attributes

None

 

Example

 

30

972-3-9225252 Ext. 918

2400

Call completed successfully

20070321 11:41:10

1

 


TYPE

TYPE is used to specify the Device type of the recipient device. This element’s value is determined as follows:

 

Type Description

10 Mobile Phone

20 Business Phone

30 Home Phone

40 Email

60 SMS

80 Fax

120 MMS

 

MMS Notes:

1) Not all countries and service levels support sending and/or receiving MMS messages. Please contact support for a list of supported countries and service levels. For most countries you will get failed status for sending message with type=”MMS” (see Error & Status Codes).

2) In order to send MMS as slide show, insert SMIL (according to http://www.ietf.org/rfc/rfc4536.txt) as file attachment (see section Z. FILE_MESSAGE), else if you use regular file attachment (section Z. FILE_MESSAGE) default SMIL will be created.

 

DTD Fragment

<!ELEMENT TYPE (#PCDATA)>

 

Structure

TYPE must appear once in the DEVICE.

 

Attributes

None

 

 

Example

30


VALUE

VALUE is used to specify the device value. This is the actual destination of the device. The value can be a phone number, email address etc. depends on the TYPE of the device.

 

DTD Fragment

<!ELEMENT VALUE (#PCDATA)>

Structure

VALUE must appear once in the DEVICE

 

Attributes

None

 

Example

972-3-9225252 Ext. 918


STATUS

STATUS is used to specify the Device status value of the recipient device. This element’s value is determined as described in Error & Status Codes  and the Error and Description and Status Codes Table

 

DTD Fragment

<!ELEMENT STATUS(#PCDATA)>

Structure

STATUS must appear once in the DEVICE

 

Attributes

None

 

Example

2400


DESCRIPTION

DESCRIPTION is used to specify the Device status’s description. This actually the description as mentioned in Error and Description and Status Codes Table

 

DTD Fragment

<!ELEMENT DESCRIPTION (#PCDATA)>

Structure

DESCRIPTION must appear once in the DEVICE

 

Attributes

None

 

Example

Call completed successfully


STATUS_DATE

 

STATUS_DATE is used to specify time the current status was given.

DTD Fragment

<!ELEMENT STATUS_DATE (#PCDATA)>

Structure

STATUS_DATE may appear once in the DEVICE. The content of the tags should conform to the following format: yyyymmdd hh:mm:ss.

 

Attributes

None

 

Example

< STATUS_DATE > 20070322 15:14:58


ANSWER

ANSWER is used to contain the text of the message’s reply.

 

DTD Fragment

<!ELEMENT ANSWER (#PCDATA)>

Structure

ANSWER may appear once in the DEVICE

 

Attributes

None

 

Example

1