How to Solve the Business Standards Dilemma – The CCTS ......Business data interoperability is...

How to Solve the Business Standards Dilemma – The CCTS based Core Data Types

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2006 SAP AG 1


Applies to: SAP NetWeaver

Summary Previous articles of the series "How to Solve the Business Standards Dilemma" focused on the key aspects and principles of the ISO 15000-5 Core Components Technical Specification (CCTS) so far. The first article – The Context Driven Business Exchange – gives a good overview of the CCTS approach, where the second article – CCTS Key Model Concepts – shows the key concepts that are necessary for understanding the CCTS based modeling. Business data interoperability is based on a common understanding of the meaning of information. According to the CCTS approach, data modeling is performed on the basis of commonly accepted and publicly available Core Components and its related Business Information Entities. As the smallest building block in the data modeling hierarchy proposed by the UN/CEFACT, the Core Data Types (CDTs) represent an unambiguous basis of atomic business information parts that are used to assemble all higher level parts up to a complete business document. CDTs do have only a primarily business meaning and can thus be used by all existing Basic Core Components (BCCs) and their affiliated contextualized Basic Business Information Entities (BBIEs) as a means for characterizing the actual type of information (e.g. Amount, Identifier, etc.) To allow for data interoperability also on this data type level and to prevent modelers from describing data contained in their business documents in an arbitrary fashion, the UN/CEFACT has defined and published 21 different CDTs (along with detailed rules for restricting them to meet individual requirements) that should be adequate to reflect the characteristics of every possible data item. CDTs always comprise exactly one so called content component and one or more several so called supplementary components. Content Components are designed to express the actual value carried by a Core Data Type. They are based on primitive types such as decimal, integer, string, etc.. Supplementary Components provide additional information such as the “nature of the identification scheme or code list, the owner of the scheme, its Uniform Resource Identifier and so on.” The specification of the CDTs aims at improving interoperability by adhering to the following three principles:

• Consideration of only the most relevant smallest business aspects by each CDT

• Establishment of a fairly small list of CDTs that is maintained by only one international agency (UN/CEFACT)

• Specification of restriction rules that only reflect the restriction according business requirements and not technical requirements

In order to reduce the TCO in integration/development of applications and to enable a high reusability of existing modeling artifacts, it is a prerequisite to get a common and unambiguous understanding of all business oriented interfaces. The CCTS CDTs are a very helpful step toward reaching this goal. For this reason, all interfaces of SAP’s Enterprise Services are using reusable building data blocks (SAP Global Data Types), which adhere to the CCTS approach and are only based on one of the predefined CCTS CDTs. Author: Gunther Stuhec Company: SAP AG Created on: 07 November 2006



Author Bio Since his master's degree (MSC, 1993) Gunther Stuhec has worked with communications and EDI technologies. As a consultant in a software house for middleware and EDI systems he developed strategic concepts for customers and was responsible for various EDI projects. He joined SAP SI as a consultant in 1999, where he was responsible for implementing XML/EDI projects in conjunction with SAP systems. Since 2001 Mr. Stuhec works for SAP AG as a “Standards Architect” and has been involved in standardizing business standards on both semantic and syntax levels.

Gunther is the chair of the UN/CEFACT Techniques and Methodologies Group (TMG) that is responsible for the development and maintenance of the UN/CEFACT CCTS standard. He is also the chair of the UN/CEFACT’s project team that develops the CCTS standard. Furthermore, he is a member of various international and national standardization bodies like UN/CEFACT, ISO TC 154, and DIN. He is actively involved in developing standards and serves as an interface between these bodies and SAP, introducing SAP's requirements into their work and incorporating their latest findings into SAP's development activities.



Table of Contents

Key principles of Core Data Types .............................................................................................. 4 Modeling Elements of Core Data Types ...................................................................................... 5 Core Data Types for Numerical Values ....................................................................................... 8

Numeric. Type .......................................................................................................................... 8 Percent. Type ........................................................................................................................... 8 Ratio. Type ............................................................................................................................... 9 Value. Type .............................................................................................................................. 9

Core Data Types for Numeric Values with Units ....................................................................... 10 Amount. Type ......................................................................................................................... 10 Measure. Type........................................................................................................................ 10 Quantity. Type ........................................................................................................................ 11

Core Data Types for Codes, Identification and Indication ......................................................... 12 Code. Type ............................................................................................................................. 12 Identifier. Type........................................................................................................................ 13 Indicator. Type........................................................................................................................ 13

Core Data Types for Dates and Times ...................................................................................... 14 Date. Type .............................................................................................................................. 14 Date Time. Type ..................................................................................................................... 15 Duration. Type ........................................................................................................................ 16 Time. Type.............................................................................................................................. 16

Core Data Types for Textual Information................................................................................... 17 Text. Type............................................................................................................................... 17 Name. Type ............................................................................................................................ 17

Core Data Types for Binary Information .................................................................................... 18 Binary Object. Type ................................................................................................................ 18 Graphic. Type ......................................................................................................................... 19 Picture. Type .......................................................................................................................... 19 Sound. Type ........................................................................................................................... 20 Video. Type ............................................................................................................................ 20

Introduction The ISO 15000-5 CCTS (Core Components Technical Specification) developed by both the UN/CEFACT and ISO provides a methodology for semantic data modeling that achieves a common understanding of data structures and message types on a syntax independent level. SAP supports ISO 15000-5 CCTS for defining the SAP Global Data Types (GDTs) as a basis of Business Objects and Enterprise Services in order to provide the highest level of semantic interoperability between SAP and non-SAP applications. The so called



complexSAP GDTs, which are representing aggregated types, are comparable with CCTS Aggregate Business Information Entities. All leaf elements of these SAP GDTs are based on a specific predefined CDT. A SAP GDT leaf element is comparable with a BBIE (Basis Business Information Entity).

Key principles of Core Data Types A “Core Data Type” defines the smallest piece of business information by thoroughly characterizing the nature of a BCC’s or BBIE’s content. These Core Data Types are considered as generic data types in data structures and information exchanges – such as Amount, Code, Identifier, Indicator, Measure, Name, or Quantity. The CCTS provides a fixed list of these Core Data Types. Every Core Data Type provides supplementary information that gives essential extra definition to the content. As shown in Figure 1, the content is expressed by one single Content Component that is always based on a primitive type such as decimal, integer, string and others. The supplementary information to the content is expressed be one ore more Supplementary Components. Supplementary Components might include the nature of the identification scheme or code list, the owner of the scheme, its Uniform Resource Identifier and so on. Such metadata provides additional information necessary for the understanding of the primary business information. For example, the Content Component of “Amount. Type” is based on a decimal primitive type. This “Amount. Type” has also one additional Supplementary Component that represents the currency of each content.

Figure 1 - Core Data Type Concept

forcreation

of

ContentComponent

carries the actual value

ContentComponent


1

CoreDataType

CoreDataType

SupplementaryComponent

gives extra definition to the value



1..n

forcreation

of

ContentComponent


ContentComponent


1

CoreDataType

CoreDataType





1..n

<Term>. TypeAmount. Type

[?<Qualifier>_*] <Term>. [?<Qualifier>_*] <Term>. <Term>Spare Part_ Item. Value Added_ Tax. Amount

Core DataType (CDT)

Object Class

Representation

Qualified DataType (QDT)

4Basic Business Information Entity (BBIE)

5

1

23

4

Object Class

Representation

Property

Representation

Object Class

[?<Qualifier>_*] <Term>. TypeValue Added_ Tax_ Amount. Type

3

In case the business context of a specific user requires a data type to account for certain restrictions, a so-called Qualified Data Type (QDT) can be created on the basis of a Core Data Type. A QDT can be considered as a CDT featuring certain restrictions that are represented with the help of the abovementioned Supplementary Components.

As visualized in Figure 1, BBIEs are always affiliated with either a CDT (Arrow ) or a QDT (Arrow ) via the Representation Term (RT): the lowest line of the graph shows the general composition of a BBIE,



comprising the Object Class Qualifier (OCQ), Object Class Term (OCT), Property Qualifier (PQ), Property Term (PT) and the Representation Term (RT). In case a user’s business context does not impose constraints on the underlying data types, the Object Class Term (OCT) of a proper generic CDT is used as RT of the BBIE (Arrow ). In the case some restrictions on type level have to be applied (for e.g. length of content) for a specific business circumstance (for e.g. for restricted representation of a “Value Added Tax Amount”, a so called Qualified Data Type (QDT) must be defined. This QDT must be semantically qualified by adding Object Class Qualifiers (OCQ) with appropriate business meaning (e.g. “Value Added_ Tax_” in front of the Object Class Term (for e.g. “Amount. Type”.). The QDT must be based on a predefined CDT and must have the same terms as the CDT (Arrow and ). If the BBIE has the same terms and qualifiers (e.g. Value Added_ Tax) in its Property as the qualifiers (e.g. Value Added_ Tax_) of a defined QDT (Arrow ), it must be based on this specific QDT. It could be also possible that the another QDT has further qualifiers (for e.g. Spare Part_ Item_) that also fit to the qualifiers and term of a BBIEs Object Class (Arrow ), which means that this BBIE must be based on the more restricted QDT that has the additional qualifiers.

Modeling Elements of Core Data Types The modeling of CDT-elements is based on a diagram that is related to typical UML class icons. The key point of differentiation is that the so-called CDT icon provides all semantically specific information and all characteristics very precisely in the form of a table. As shown in Figure 2, this semantically specific information and characteristics are clearly separated in this table in compliance with the CCTS and ISO 11179 rules.

Figure 2 – Core Data Type Modeling Elements

This CDT icon considers the following information:

• <<CDT>> – is the stereotype of the whole type. It is always a “Core Data Type”

• Amount. Type – is the name of Core Data Type according the CCTS Dictionary Entry Name rules.

• <<CC>> – is the stereotype of the first attribute within in the Core Data Type. It is always a “Content Component”.

• <<SC>> – is the stereotype of all subsequent stereotypes. These are always Supplementary Components

• OCT – this column describes the Object Class Term of the content component or supplementary components

• PT – this column describes the Property Term of the content component or supplementary components



• RT – this column describes the Representation Term of the content component or supplementary components

• Occ. – represents the cardinality of the of the content component or supplementary component

• The content component is always mandatory (1..1) and the supplementary components could be mandatory (1..1) or optional (0..1).

• Base Type – this column shows the base types of a content component or supplementary components

o xsd:<built-in data type> – the base type is only represented as XSD built-in data type, because this allows a better association to the XML syntax dependent “Core Data Types” as described in UN/CEFACT XML NDR for CCTS Version 2.0, which is also originally used in SAP NW. Either the content component or supplementary component could be based on XSD built in types.

o <name>CodeList – this is the name of the code list scheme module, if a supplementary component is using a code list.

• Restriction – shows the restriction facets or information about each content component and supplementary component.

o length – shows the restricted maximum or fixed length or a content component or supplementary component. The represented restrictions are only defined only SAP and are currently not specified in the relevant UN/CEFACT CCTS standards. Reasons for length restrictions are physical restrictions of data base tables and user interfaces. It could be:

<n> - Fixed length of <n> characters/digits

<m>.<n> - Maximum length of <m> premedical digits and <n> fractional digits

<m>..<n> - Minimum length of <m> characters and maximum length <n> characters

..<n> - Maximum length of <n> characters

o Pattern – represents a regular expression that restricts the value pattern of a content component or supplementary component

<CodelistIdentifier>:<CodelistVersion>:<CodelistAgencyIdentifier> – this URN identifies the specific codelist on which a supplementary component is based on. The construct follows the supplementary components for the identification of codelist that are defined in Code. Type. See chapter “

o Code. Type” at page 12.



List of Permissible Core Data Types This chapter includes the list of 21 permissible Core Data Types that are originally defined as primary and secondary representation terms in ISO 15000-5 - CCTS (Core Component Technical Specification) Version 2.01. This kind of definition follows exactly the UN/CEFACT XML NDR V2.0 approach1. The next version of CCTS2 has no separation of secondary and primary representation, because this caused some confusion. The next version of CCTS will exactly follow the same approach as described in this article. Each representation term will refer to one appropriate of the 21 permissible Core Data Types that are also listed in Appendix A3. As mentioned before, the primary representation syntax language of SAP NW is XML. SAP NW defined these representation terms as individually defined data types that are represented by the W3C XML Schema Definition Language. This is also comparable to UN/CEFACT XML Naming and Design Rules for CCTS - Version 2.0. All the content components and supplementary components of these CDTs are based on XML-scheme-specific built-in data types. Furthermore, these CDTs consider only the required supplementary components. In order to facilitate interoperability the constructs must be restricted as much as possible. For example alternative code lists for the representation of currency in “Amount. Type” lead automatically to different interpretations and representations. A supplementary mapping between these code lists is always required and do not serve to assist interoperability. Therefore, these supplementary components for defining formats or alternative code lists are not defined. The listed Core Data Types are categorized in the following categories:

• Core Data Types for representation of only numerical values

• Core Data Types for numerical values with coded supplementary information

• Core Data Types for coded representation, identification or indication

• Core Data Types for textual and string based representation

• Core Data Types for binary representation, like pictures, photographs, sounds, videos, etc. SAP NW considers also the CDTs “Attachment. Type”, “Description. Type”, and “Note. Type”, that are currently not a part of the ISO 15000-5 CDT. “Description. Type”, and “Note. Type” are normally Qualified Data Types “Description_ Text.Type” and “Note_ Text. Type” that are based on the CDT “Text. Type”. The

1 UN/CEFACT XML NDR 2 See “CCTS draft version”: http://www.untmg.org/index.php?option=com_docman&task=docclick&Itemid=137&bid=43&limitstart=0&limit=5 3 See: „CCTS draft version – Appendix A: Core Data Types“: http://www.untmg.org/index.php?option=com_docman&task=docclick&Itemid=137&bid=42&limitstart=0&limit=5

http://www.untmg.org/index.php?option=com_docman&task=docclick&Itemid=137&bid=43&limitstart=0&limit=5






reason for these additional definitions is a specific rule of UN/CEFACT XML Naming and Design Rules for CCTS - Version 2.0. It allows the truncation of “Text” in elements (BBIEs). Because, “Description” and “Note” are the only elements that are based on “Text”, SAP NW considers these two as additional Core Data Types.

Core Data Types for Numerical Values These Core Data Types are required for only representing numerical values without some supplementary information. These values could be counting information, factors, ranking, calculations, percents, etc. These CDTs primarily based on the W3C XML-scheme-specific build-in data type xsd:decimal. Therefore, it is not required to provide the additional supplementary component “…. Format. Text” because the format is exactly represented by this build-in data type.

Numeric. Type A “Numeric. Type” is a decimal value for the representation of only numerical information that can not show as a percent, ratio of value. As shown the the Figure 3, only the content component of “Numeric. Type” is relevant, and it could be represented as positive and negative numeric values. It can be realized be by using the built-in data type “xsd:decimal”.

Figure 3 - Structure of "Numeric. Type"

“Numeric. Type” could be used for the following business relevant representations:

• The numeric factor expressed as a number applied to calculate the allowance charge such as 1.1

• A numeric value of the the priority ranking of the type of construction.

• A numeric evaluation score of the examination result

Percent. Type A “Percent. Type“ is a number that relates to the comparison figure 4. “Percent. Type” is derived from “Numeric. Type”. The representation from content component is als based on xsd:decimal, but especially the SAP’s CDT is restricted to 10 integer-digits and 6 fraction digits (see Figure 4).



Figure 4 - Structure of "Percent. Type"

The “Percent. Type” could be used for the following business relevant representations:

• The percentage of goods or services completed for this contract.

• A percentage measurement of one object as part of another object for this specific metric or set of metrics

• A percentage of the total estimated price that constitutes the minimum threshold price.

Ratio. Type A “Ratio. Type” is the relationship between two quantities, which is expressed as the quotient of the division of numerator by denominator. “Ratio. Type” is derived from “Numeric. Type”. The representation from content component is als based on xsd:decimal, but especially the SAP’s CDT is restricted to 22 integer-digits and 14 fraction digits (see Figure 5)

Figure 5 - Structure of "Ratio. Type"

The “Ratio. Type” could be used for the following business relevant representations:

• A ratio that is used to convert one quantity into another

• A ratio at which costs are calculated

• A ratio that expresses the average of a calculation.

Value. Type A “Value. Type“ expresses the concept of numeric worth in general. “Value. Type” is derived from “Numeric. Type”. Therefore, the representation from content component is exactly the same (see Figure 6).

Figure 6 - Structure of "Value. Type"



The “Value. Type” could be used for the following business relevant representations:

• A value of the allocation base used in an assessment or distribution.

• A value-based specification of a priority.

• A value of a check digit for a bank account number.

Core Data Types for Numeric Values with Units These Core Data Types represents numeric values that require supplementary information for showing the exact information. These are amounts, measures, and quantities that need additional coded information about the kind of currency for amount and measure unit for measure and quantity. The CDTs that are provided by SAP NW have a content component that is based W3C XML-scheme-specific build-in data type and are restricted length, because of the reasons of physical storage and user interface representation. Furthermore, the coded supplementary components are always based on only one fixed code list that is internationally most accepted one. SAP NW does not provide alternative code lists. Therefore, it is not required to use these supplementary components that are required for identifying the code lists itself.

Amount. Type An Amount. Type is an amount with the corresponding currency unit. As shown the the Figure 7, the “Amount, Type” has a content component that is based on xsd:decimal. The SAP restricted it to 22 predecimal digits and 6 decimal digits. The “Amount. Type” has also one supplementary component for the representation of the currency unit in accordance with the ISO 4217 three-character code that is provided by ISO in 2001. The ISO is represented as code 5 from code list UNECE DE 3005.

Figure 7 - Structure of "Amount. Type"

The “Amount. Type” could be used for the following business relevant representations:

• The monetary value that is the basis on which the allowance or charge is calculated.

• A monetary value of a price of this contract.

• The monetary amount of liability for this guarantee.

• A monetary value of the funds or securities to be paid by this means of payment.

Measure. Type A “Measure. Type” is a physical measurement with the corresponding unit of measurement. The measure is the result of the measurement of a physical size in relation to a standard size, which is the standard against which everything else is measured. As Figure 8 shown, positive and negative entries are possible by using the built-in data type “xsd:decimal”. This content is restricted by SAP NW to a maximum of 13 predecimal digits and 6 fraction digits. The



“Measure. Type” has a supplementary component for the representation of the measurement units in accordance with UN/ECE (6) Recommendation #20.

Figure 8 - Structure of "Measure. Type"

The “Measure. Type” could be used for the following business relevant representations:

• A measure of a width for this dimension.

• The measure of the altitude that reflects the vertical elevation of an object above a surface for this geographical coordinate (Reference ISO 6709).

• A measure of the temperature for the test condition.

Quantity. Type A Quantity. Type is the non-monetary numerical specification of an amount in an unit of measurement. A quantity is the result of the numerical comparison of the number, amount, or size of a given item or attribute and a standard number, amount, or size. Depending on the item or attribute to be qualified and the business context, the comparison can be made by physically measuring or counting. As Figure 9 shown, positive and negative entries are possible by using the built-in data type “xsd:decimal”. This content is restricted by SAP NW to a maximum of 13 predecimal digits and 6 fraction digits. The “Quantity. Type” has a supplementary component for the representation of the measurement units in accordance with UN/ECE (6) Recommendation #20. Figure 9 - Structure of "Quantity. Type"

The “Quantity. Type” could be used for the following business relevant representations:

• The quantity on which the allowance or charge is based.

• A number of employees for this business profile.

• A quantity for a specific item in this contract.



Core Data Types for Codes, Identification and Indication These Core Data Types should be especially used for the identification of objects, coded representation of information, or Boolean indication according of the mathematical concept of binary-valued logic. The ISO 15000-5 - CCTS (Core Component Technical Specification) Version 2.01 defines a number of more supplementary components for these Core Data Types. But these supplementary components are not necessary, because Core Data Types of SAP NW are more restricted and reflect only a specific code list or based on a specific W3C XML-scheme-specifc build-in data type. The chapter describes only the structure and characteristics of the Core Data Types “Code. Type” and “Identifier. Type”. The detailed description about the exact usage and its differentiation requires more background about the codes and identifiers. Therefore, this will follow in the article “How to Solve the Business Standards Dilemma – Codes vs. Identifiers”

Code. Type A Code. Type is a character string of letters, numbers, special characters (except escape sequences), and symbols. It represents a definitive value, a method, or a property description in an abbreviated or language-independent form. Figure 10 shows that the content component of “Code. Type” is based on xsd:token. It has also a number of supplementary components that are primarily used for the unique identification of a code list that is used for the representation of the code value itself. The following supplementary components can be used:

• Code List. Identification. Identifier – Identifies a code list that includes unique code values. A code value could be a unique abbreviation or acronym of a description, text, or method. Every code list differs significantly according the requirements of each responsible agency that wants to identify objects uniquely with it. SAP specific CDT has a restricted maximum length of 60 characters.

• Code List. Version. Identifier – Identifies the version of a code list. SAP specific CDT has a restricted maximum length of 15 characters.

• Code Liust. Agency. Identifier – Identifies the agency that provides and maintains a code list. This agency must ensure that only unique code values will be issued by its scheme. The agencies from UN/CEFACT DE 3055 are used as default, but the roles defined in DE 3055 cannot be used. It is also possible to use URI’s instead of DE 3055, if the responsible agency is not listed in DE 3055. SAP specific CDT has a restricted maximum length of 60 characters.

Figure 10 - Structure of "Code. Type"

The “Code. Type” could be used for the following business relevant representations:

• A code specifying the reason for an allowance charge.

• A code specifying a classification of the business in a profile.



• A code specifying a type of contract such as a fixed price contract or a time and materials based contract.

Identifier. Type An Identifier. Type is a unique identification of an object within an identification scheme that is managed by an agency. There are usually multiple identification schemes for identifying an object. Figure 11 shows that the content component of “Identifier. Type” is based on xsd:token. It has further supplementary components for the unambiguous identification of the identification scheme that is used for the representation of the identifier value. The following supplementary components can be used:

• schemeID – Identifies an identification scheme that represents a numbering system to identify uniquely an object within this scheme. A scheme is a concept connecting the fields of a number theory that includes rules of a numbering system, number ranges, and structuring. Identifier values of a scheme could be concatenated from several numbering parts that guarantees the uniqueness of an identifier within the defined scheme. Every identification scheme differs significantly according the requirements of each responsible agency that wants to identify objects uniquely with it. SAP specific CDT has a restricted maximum length of 60 characters.

• schemeVersionID – Identifies the version of an identification scheme. SAP specific CDT has a restricted maximum length of 15 characters.

• schemeAgencyID – Identifies the agency that provides and maintains an identification scheme. This agency must ensure that only unique identifiers will be issued by its scheme. The agencies from UN/CEFACT DE 3055 are used as default, but the roles defined in DE 3055 cannot be used. It is also possible to use URI’s instead of DE 3055, if the responsible agency is not listed in DE 3055. SAP specific CDT has a restricted maximum length of 60 characters.

Figure 11 - Structure of "Identifier. Type"

The “Identifier. Type” could be used for the following business relevant representations:

• An identifier identifying uniquely objects, assets, or products

• An identifier identifying uniquely transactions

• An identifier identifying uniquely events

• An identifier referencing to other identifiers

Indicator. Type An “Indicator. Type“ is the representation of a situation that has exactly two mutually exclusive Boolean values.



The content component of “Indicator. Type” can have the following values:

• true – Positive indicator value

• false – Negative indicator value

•

Figure 12 - Structure of "Indicator. Type"

“Indicator. Type” can be used for example:

• An indication of whether or not the allowance charge is prepaid.

• An indication of whether or not the examination results in approval.

• The indication of whether or not a requirement exists for these instructions.

Core Data Types for Dates and Times These Core Data Types specifies the representation of dates in the Gregorian calendar and times and representations of duration in time. All Core Data Types that are used in SAP NW, are based on the date and/or time specific W3C XML-scheme-specifc build-in data types, which is also defined in UN/CEFACT XML Naming and Design Rules for CCTS - Version 2.0. These data typess are closely related to the dates and times described in ISO 8601. Therefore, it is not required to additionally define the supplementary components “<Core Data Type Term>. Format. Text” in these specific Core Data Types.

Date. Type A “Date. Type" is the specification of an exact day in the Gregorian calendar. The content component of “Date. Type” uses the W3C built-in data type xsd:date. This is structured according to the extended representation of ISO 8601 (see http://www.w3.org/TR/NOTE-datetime). The extended representation is as follows:

CCYY-MM-DD Example:

2002-04-19

Figure 13 - Structure of "Date. Type"

<<CDT>>

Type

Date. Type

OCT PT RT Restriction

<<CC>> Date. Contentlength pattern

Occ. Base Type

xsd:date1..1

The date is used to represent points in time or time stamps in which the day must be exact, for example:

http://www.w3.org/TR/NOTE-datetime



• The date value specified as a year for the completed work.

• The date on which this contract starts.

• The date of expiry up to which the financial card is valid.

Date Time. Type A “Date Time. Type“ is the accurate-to-the-second time-point of a calendar day. The content component of “Date Time. Type” is based on the W3C built-in data type xsd:dateTime. This is structured according to the extended representation of ISO 8601 (see http://www.w3.org/TR/NOTE-datetime). The extended representation is as follows:

CCYY-MM-DDThh:mm:ss(.sss)Z or

CCYY-MM-DDThh:mm:ss(.sss)(+/-)hh:mm Example:

2002-04-19T15:30:00Z or 2002-04-19T10:30:00+05:00

Figure 12 shows two supplementary components of "Date Time. Type” that are additionally defined by SAP, which are:

• Date Time. Timezone. Code – If the content contains neither offset nor Z, contains is local and this supplementary component specifies the time zone to which date and time content refers.

• Date Time. Daylight Saving Time. Indicator – Specifies if date and time content is in daylight saving time or not.

These two supplementary components allow the handling of local times without the definition of other Aggregated Business Information Entities (ABIEs). A “Date Time. Type” with an additional representaton of “Date Time. Timezone. Code” and “Date Time. Daylight Saving Time. Indicator” will be unambiguous, if especially recurring events should be calculated by usage of local date time representations

Figure 14 - Structure of "Date Time. Type"

<<CDT>>

Type

Date Time. Type


<<CC>> Date Time. Contentlength pattern

Occ. Base Type

xsd:dateTime1..1

<<SC>> Date Time. Daylight Saving Time. Indicator xsd:boolean0..1

lengthTRUE|FALSE

pattern1TZCL

ID310

V.ID A.ID<<SC>> Date Time. Time Zone. Code Timezone-

CodeList0..1

The “Date Time. Type” is used for exact time stamps that must contain the day and time. For example

• The date and time value of the conversion rate for this currency exchange.

• The date and time value for the issuance of this document.

• The date and time value of an occurrence of this event.





Duration. Type A Duration. Type is a period of time of a particular length without a fixed start or end time. This period of time is expressed in years, months, days, hours, minutes, seconds, and fractions of a second. The content component of “Duration. Type” is based on the “built-in data type” of W3C xsd:duration. This is structured according to the extended representation of ISO 8601 (see http://www.w3.org/TR/xmlschema-2/#isoformats ). The representation is as follows: PnYnMnDTnHnMnS Example: P12Y12M2DT4H12M40S

Figure 15 - Structure of "Duration. Type"

<<CDT>>

Type

Duration. Type


<<CC>> Duration. Contentlength pattern

Occ. Base Type

xsd:duration1..1

Duration describes a time period with a particular length of an event or process. For instance:

• working time,

• duration of stay, or

• processing time. However, it is not dependent on a fixed point in time.

Time. Type A Time. Type since begin of day in a 24 hour day.

Figure 16 - Structure of "Time. Type"

<<CDT>>

Type

Time. Type


<<CC>> Time. Contentlength pattern

Occ. Base Type

xsd:time1..1

The “Duration. Type” could be used for a time period with a particular length of an event or process. For instance:

• The duration for which something is planned.

• The duration of probation time of an employee.

• The duration between placing the order and the receiptof delivery.

http://www.w3.org/TR/xmlschema-2/#isoformats

http://www.w3.org/TR/xmlschema-2/#isoformats



Core Data Types for Textual Information Core Data Types for textual information are used for representation of character string based information, like description, notes, and names. The origin Core Data Type is “Text. Type”. This Core Data Type defines the general structure for an unambiguous representation of textual information. The Core Data Type “Name. Type” has exactly the same physical structure, characteristics and W3C XML-scheme-specifc build-in data type. Therefore, the content component and supplementary components are only explained in “Text. Type”.

Text. Type A Text. Type is a character string with an optional language specification. The content component of “Text. Type” could be based on the W3C XML-scheme-specifc build-in data type xsd:string. The “Text. Type” has one supplementary component, the “Text. Language. Code”. It is for the representation of language in accordance with IETF RFC 1766 or IETF RFC 3066, if the content is language dependent.

Figure 17 - Structure of "Text. Type"

The “Text. Type” could be used for:

• A description that is a representation of the properties of an object in natural language

• A note that is a natural-language comment on a situation or subject

• The purpose, expressed in text, of this document.

Name. Type A Name. Type is a word or combination of words used to name or define an object.

Figure 18 - Structure of "Name. Type"

The “Name. Type” could be used for the following reasons:

• The name of a contact person.

• The account name of a financial account.

• The name of an organization.

http://www.ietf.org/rfc/rfc1766.txt

http://www.ietf.org/rfc/rfc3066.txt



Core Data Types for Binary Information Code Data Types for binary information are used for the representation for binary objects of specific semantically driven aspects, like sound, video, graphics, photographs etc. The origin Core Data Type of binary information is “Binary Object. Type”. This Core Data Type defines the general structure and characteristics that other Core Data Types like “Graphic. Type”, “Picture. Type”, “Sound. Type”; and “Video. Type” are derived from it. These Core Data Types should be used for a specific business requirements representing binary information. The physical structure, its characteristics and the W3C XML-scheme-specifc build-in data types are exactly the same. Therefore, the content component and supplementary components are only explained in “Binary Object. Type”.

Binary Object. Type A BinaryObject. Type is a finite data stream of any number of characters in binary notation (octets). The content component of “Binary Object. Type” is based on the XML-scheme-specific built-in data type xsd:base64Binary. This enables any binary data to be rep-resented using base64 encoding. This is done using the base64 Content-Transfer-Encoding procedure. The following supplementary components can be used in “Binary Object. Type”:

• Binary Object. MIME. Code – Identifies the medium type (image, audio, video, application) of the binary content according to the MIME type definition in IETF RFC 2046 and the corresponding MIME type recommendations.

• Binary Object. CharacterSet. Code– Identifies the specific character set of text data.

• Binary Object. Format. Text – Describes the format of the binary content if the format is not clear or unique from the “Binary Object. MIME. Code”.

• Binary Object. File. Name – Contains the corresponding name or file name of the binary content according to the MIME protocol (see IETF RFC 1341).

• Binary Object. Uniform Resouce. Identifier – References the physical location of “BinaryObject” if this is represented as a MIME attachment in a SOAP message or in an ebXML-MSG message. The syntax of the URI is defined in the IETF RFC 2396 recommendation and is as follows: <scheme>.< scheme-specific part> (see Section 4.6.5 Representation).



Figure 19 - Structure of "Binary Object. Type"

2005MIMEID

IANA

V.ID A.ID

1CSCLID

310

V.ID A.ID

<<SC>> Binary Object. MIME. Code MIMEMetiaTypesCodeList0..1

<<SC>> Binary Object. Character Set. Code CharacterSet-

CodeList0..1

<<CDT>>

Type

Binary Object. Type


<<CC>> Binary Object. Contentlength pattern

Occ. Base Typexsd:based64-

binary1..1

length pattern<<SC>> Binary Object. Format. Text xsd:string0..1

<<SC>> Binary Object. File. Name xsd:string0..1length pattern

length pattern<<SC>> Binary Object. Uniform

Resource. Identifier xsd:anyURI0..1

The “Binary Object. Type” can be used for binary data and all types of binary files, and could be used for the following reasons:

• A binary object that is attached or otherwise appended to this document.

• Binary object data such as a photograph or disk recording describing this event.

Graphic. Type A Graphic. Type is a finite data stream of diagram, graph, mathematical curves, or similar vector based representation in a specific notation, which is expressed in based 64 encoding

Figure 20 - Structure of "Graphic. Type"

2005MIMEID

IANA

V.ID A.ID

1CSCLID

310

V.ID A.ID

<<SC>> Graphic. MIME. Code MIMEMetiaTypesCodeList0..1

<<SC>> Graphic. Character Set. Code CharacterSet-

CodeList0..1

<<CDT>>

Type

Graphic. Type


<<CC>> Graphic. Contentlength pattern


binary1..1

length pattern<<SC>> Graphic. Format. Text xsd:string0..1

<<SC>> Graphic. File. Name xsd:string0..1length pattern

length pattern<<SC>> Graphic. Uniform


“Graphic. Type” can be used for representing vector based graphics, like CAD drawings, diagrams, graphs, mathematical curves and chars, which will be represented as binary data and all types of binary files. This graphics could be also shown as binary displayed documents (such as PDF, DOC, and XLS files).

Picture. Type A Picture. Type is visual representation of a person, object, or scene in binary notation (octets).



Figure 21 - Structure of "Picture. Type"

2005MIMEID

IANA

V.ID A.ID

1CSCLID

310

V.ID A.ID

<<SC>> Picture. MIME. Code MIMEMetiaTypesCodeList0..1

<<SC>> Picture. Character Set. Code CharacterSet-

CodeList0..1

<<CDT>>

Type

Picture. Type


<<CC>> Picture. Contentlength pattern


binary1..1

length pattern<<SC>> Picture. Format. Text xsd:string0..1

<<SC>> Picture. File. Name xsd:string0..1length pattern

length pattern<<SC>> Picture. Uniform


Picture can be used for binary data of pictures, photos, arts, clip arts which are represented in a binary notation.

Sound. Type A Sound. Type can be used for all kinds of audio files. This includes files such as audio recordings in binary notation (octets).

Figure 22 - Structure of "Sound. Type"

Sound can be used for voice, sound and music streams, which are represented in binary data and all types of binary files.

Video. Type A Video. Type is elating to the recording, reproducing or broadcasting of visual images on magnetic tape or digitially in binary notation (octets).



Figure 23 - Structure of "Video. Type"

2005MIMEID

IANA

V.ID A.ID

1CSCLID

310

V.ID A.ID

<<SC>> Video. MIME. Code MIMEMetiaTypesCodeList0..1

<<SC>> Video. Character Set. Code CharacterSet-

CodeList0..1

<<CDT>>

Type

Video. Type


<<CC>> Video. Contentlength pattern


binary1..1

length pattern<<SC>> Video. Format. Text xsd:string0..1

<<SC>> Video. File. Name xsd:string0..1length pattern

length pattern<<SC>> Video. Uniform


“Video. Type” can be used for video sequences, movies, films which are represented in binary files.

Related Content Overview of ISO 15000-5 / UN/CEFACT Core Components Technical Specification (UN/CEFACT CCTS)

How to Solve the Business Standards Dilemma - CCTS Key Model Concepts How to Solve the Business Standards Dilemma - The Context Driven Business Exchange ISO 15000-5 - CCTS (Core Component Technical Specification) Version 2.01 ISO 15000-5:2006 - CCTS (Core Component Technical Specification) Version 2.2 (draft version) ISO 15000-5:2006 - CCTS (Core Component Technical Specification) Version 2.2 (draft version) - Part B Core Data Types UN/CEFACT XML Naming and Design Rules for CCTS - Version 2.0 UN/CEFACT XML Naming and Design Rules for CCTS - Version 2.0 - XML Schemas UN/CEFACT TMG (Technology & Methodologies Group) - Core Components Working Group

https://www.sdn.sap.com/irj/sdn?rid=/webcontent/uuid/1baa57f9-0a01-0010-1684-c42a08982294

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/1b873fc3-0901-0010-f7bc-9518e1aed0cf

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/a6c5dce6-0701-0010-45b9-f6ca8c0c6474

http://www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf




http://www.disa.org/cefact-groups/atg/downloads/XML%20Naming%20And%20Design%20Rules%20V2.0.pdf

http://www.disa.org/cefact-groups/atg/downloads/www.unece.org_schemas_V2.0.zip

http://www.untmg.org/index.php?option=com_content&task=view&id=25&Itemid=55



Copyright © Copyright 2006 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.

Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

How to Solve the Business Standards Dilemma – The CCTS ......Business data interoperability is...

Documents

Transcript of How to Solve the Business Standards Dilemma – The CCTS ......Business data interoperability is...