| Standards for Technology in Automotive Retail |
| Home - News Feed

1.3. The Difference Between Guidelines, Standards and Recommendations
Prev | Chapter 1. Background | Next

## 1.3. The Difference Between Guidelines, Standards and Recommendations

What is a STAR Standard?

STAR standards are used for the movement of data between any two entities within the retailing industry. The STAR standards are comprised of three components, which can be likened to a railroad system:

- A. Content or cargo stored in the railroad car (or boxcar)

- B. Transport - The railroad car (or boxcar) itself

- C. Infrastructure - The train tracks that the entire train moves on

STAR standards address all three of these components for moving data. To be STAR compliant, one must adhere to all three components of the STAR standards; data, transport, and infrastructure. The goal of STAR is to encourage, not enforce the usage of these standards. STAR has identified levels or Profiles within each component to identify the progress of compliance and to accelerate interoperability.

STAR Transport Guidelines are standards based. These standards follow a hierarchy of importance. First and foremost, STAR adheres to profiles that are approved by the WS-I. In the absence of WS-I profiles, STAR adheres to canonical standards from public standards bodies such as OASIS and W3C. Finally, in cases where the previous two principles cannot be applied, STAR may select specifications or standards based on key industry directions or vendor recommendations. As OASIS, W3C, and WS-I publish profiles and standards; the STAR Transport Guidelines will be reviewed and revised as needed.

There is currently great industry backing and momentum around Web services specifications by many web service tooling vendors. ebMS specifications are also subject to change, but there these have stabalized and there does not seem to be the same momentum driving ebMS changes as there is Web services. STAR members are advised to assess the ability to adapt their implementations to changes in the profiles and standards as they emerge from OASIS, W3C, and WS-I. STAR will incorporate these changes according to the principles above, considering the time necessary to implement those changes in affected systems.

Guidelines

STAR Guidelines in this document are defined as Requirements and/or Recommendations that are necessary to build interoperable systems between STAR trading partners. The guidelines rely on Standards defined in the IT industry from OASIS, W3C, and WS-I. These guidelines provide an overview of how the various standards and related specifications should be applied to achieve interoperability.

Specifications

STAR Specifications are companion documents to this document that describe specific implementation details that are necessary for completeness. The Specification documents from STAR may include both required and recommended items necessary to implement applications that are STAR interoperable.

Requirements

A Requirement in this document is defined as an item or process that is required for interoperability within the STAR XML Infrastructure. An item/process is determined to be a Requirement if either a system failure or interoperability failure will occur upon its removal.

Recommendations

A Recommendation is a preferred method for implementation or an optional element within the STAR XML Infrastructure. An item/process will be assigned a Recommendation status if its removal will not cause a system failure or interoperability failure to occur. If a STAR XML Infrastructure participant chooses not to implement a Recommendation, other STAR XML Infrastructure participants may choose to question the rationale, but overall the system integrity will remain intact.

Key Words

STAR Transport group uses the ITEF RFC 2119 for definitions of MUST, SHOULD, and MAY. In effect these terms mean:

- Must - Indicates an absolute requirement. Synonyms are REQUIRED and SHALL.

- Should - Indicates that there are valid reasons not to comply, but full implications must be understood and weighed. Synonym is RECOMMENDED.

- May - Indicates an item that can be implemented or not depending on situational needs. Synonym is OPTIONAL.

Those doing the implementation must give careful consideration of alternatives allowed through SHOULD and MAY with respect to interoperability between STAR trading partners.

STAR Interoperability Testing

Interoperability insures that implementations of the STAR specifications, standards, and recommendations from various development teams with various products will be compatible with predictable results when they interact. However, there is no STAR testing laboratory or facility that conducts the work of validating implementations against these guidelines. Therefore it is the responsibility of each development team to verify interoperability through various means.

Given the number of ebXML and Web services vendors in the marketplace, exhaustive interoperability testing of a system implementation with all other implementations is unreasonable. Yet careful unit testing coupled with published independent interoperability testing results can produce a high level of confidence in the ability of a system to predictably interact with other systems.

One of the benefits of specifying the ebMS standard is the interoperability testing that has been conducted by several organizations. ebMS interoperability testing is normally part of a larger interoperability testing effort for ebXML. Products that have passed ebXML interoperability testing have demonstrated the ability to operate in a heterogeneous environment with other ebXML products. STAR recommends that interoperability test results be used during product evaluations, but STAR does not endorse any particular tests at this time.

The value of the Web Services Interoperability (WS-I) organization is the interoperability profiles that they publish. These profiles describe the set of WS specifications that comprise a platform for deploying web services that will interoperate with other web services. WS-I has also published a set of testing profiles to be used by product vendors and specification implementers to allow self-testing.

Prev | Up | Next
1.2. Scope | Home | 1.4. Overall Requirements