UDDI Spec TC

 

UDDI Registry tModels, Version 2.04

11 December 2002

 

Document identifier:

UDDI_Registry_tModels

Location:

http://uddi.org/taxonomies/UDDI_Registry_tModels.htm

Editors:

Toufic Boubez

Luc Clément, Microsoft

Abstract:

This document contains the Registry tModel definitions -- those that constitute the UDDI APIs.

Status:

This document is updated periodically on no particular schedule.

Committee members should send comments on this Committee Specification to the uddi-spec@lists.oasis-open.org list. Others should subscribe to and send comments to the uddi-spec-comment@lists.oasis-open.org list. To subscribe, send an email message to uddi-spec-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message.

For information on whether any intellectual property claims have been disclosed that may be essential to implementing this Committee Specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the UDDI Spec TC web page (http://www.oasis-open.org/committees/uddi-spec/).

Copyrights

Copyright © 2001-2002 by Accenture, Ariba, Inc., Commerce One, Inc., Fujitsu Limited, Hewlett-Packard Company, i2 Technologies, Inc., Intel Corporation, International Business Machines Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc., and VeriSign, Inc.  All Rights Reserved.

 

Copyright  © OASIS Open 2002. All Rights Reserved.

 

Table of Contents

1      UDDI Inquiry APIs (Version 1) 3

2      UDDI Inquiry APIs (Version 2) 4

3      UDDI Publication APIs (Version 1) 6

4      UDDI Publication APIs (Version 2) 8

5      UDDI Taxonomy API (Version 1) 10

6      UDDI Taxonomy API (Version 2) 11

7      References. 12

Notices. 13

 

 

1      UDDI Inquiry APIs (Version 1)

1.1 Introduction

This tModel is one of several tModels that collectively represent the UDDI programming interface for UDDI V1. The group of messages represented by this tModel deals with finding and retrieving information from the registry. To be a compliant UDDI Version 1 registry, at least one of the registry nodes must provide a web service that implements this tModel. UDDI Version 2 compliant registries also must have at least one of its registry nodes provide a web service that implements this tModel. In addition at least one of the version 2 registry nodes must also provide a web service that implements uddi-org:inquiry_v2, which supercedes this tModel.

1.2 Design Goals

The design goal for the version 1.0 UDDI inquiry API is to provide a simple, complete set of messages required to:

  • Search a UDDI registry to locate registry entries meeting a particular technical or business need.
  • Retrieve details of registry entries once they have been found.

1.3 tModel Definition

The details of the version 1.0 uddi-org:inquiry APIs are covered in the UDDI Programmer’s API Specification [3].

1.3.1 tModels

Name: uddi-org:inquiry

Description: UDDI Inquiry API - Core Specification

tModel UUID: uuid:4CD7E4BC-648B-426D-9936-443EAAC8AE23

Categorization: specification, xmlSpec, soapSpec, wsdlSpec

1.3.1.1 tModel Structure

<tModel tModelKey="uuid:4CD7E4BC-648B-426D-9936-443EAAC8AE23">

  <name>uddi-org:inquiry</name>

  <description xml:lang="en">UDDI Inquiry API - Core Specification</description>

  <overviewDoc>

    <description xml:lang="en">

      This tModel defines the inquiry API calls for interacting with a V1 UDDI

      node.

    </description>

    <overviewURL>

      http://www.uddi.org/wsdl/inquire_v1.wsdl

    </overviewURL>

  </overviewDoc>

  <categoryBag>
    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="specification"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="xmlSpec"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"  

      keyName="types"

      keyValue="soapSpec"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"  

      keyName="types"

      keyValue="wsdlSpec"/>

   </categoryBag>

</tModel>

 

1.3.2 Messages covered

The UDDI messages covered by this tModel are:

  • find_binding: Used to locate specific bindings within a registered businessService. Returns a bindingDetail message.
  • find_business: Used to locate information about one or more businesses. Returns a businessList message.
  • find_service: Used to locate specific services within a registered businessEntity. Returns a serviceList message.
  • find_tModel: Used to locate one or more tModel information structures. Returns a tModelList structure.
  • get_bindingDetail: Used to get full bindingTemplate information suitable for making one or more service requests. Returns a bindingDetail message.
  • get_businessDetail: Used to get the full businessEntity information for a one or more businesses. Returns a businessDetail message.
  • get_businessDetailExt: Used to get extended businessEntity information. Returns a businessDetailExt message.
  • get_serviceDetail: Used to get full details for a given set of registered businessService date. Returns a serviceDetail message.
  • get_tModelDetail: Used to get full details for a given set of registered tModel data. Returns a tModelDetail message.

1.4 Example of Use

The following is a typical find_service message using the version 1.0 UDDI inquiry tModel:

<find_service businessKey="BK1..." generic="1.0" xmlns="urn:uddi-org:api">

  <name>Ship</name>

</find_service>

2      UDDI Inquiry APIs (Version 2)

2.1 Introduction

This tModel is one of several tModels that collectively represent the UDDI programming interface for UDDI Version 2. The group of messages represented by this tModel deals with finding and retrieving information from the registry. To be a UDDI Version 2 compliant registry at least one of the nodes in a registry must provide a web service that implements this tModel.

2.2 Design Goals

The design goal for the version 2.0 UDDI inquiry API is to provide a simple, complete set of messages required to:

  • Search a UDDI registry to locate registry entries meeting a particular technical or business need.
  • Retrieve details of registry entries once they have been found.

 

The version 2.0 UDDI specification extends the version 1.0 specification for inquiry to meet several requirements not met in version 1. In particular it provides the means to:

  • Find businessesEntities that have been related to each other by their publishers
  • Specify what to search for more flexibly and accurately. To support this several new search qualifiers have been added.

2.3 tModel Definition

The details of the uddi-org:inquiry_v2 APIs are covered in the UDDI Version 2 API Specification [1].

2.3.1 tModels:

Name: uddi-org:inquiry_v2

Description: UDDI Inquiry API Version 2 - Core Specification

tModel UUID: uuid:AC104DCC-D623-452f-88A7-F8ACD94D9B2B

Categorization: specification, xmlSpec, soapSpec, wsdlSpec

2.3.1.1 tModel Structure

<tModel tModelKey="uuid:AC104DCC-D623-452f-88A7-F8ACD94D9B2B">

  <name>uddi-org:inquiry_v2</name>

  <description xml:lang="en">UDDI Inquiry API Version 2

     - Core Specification</description>

  <overviewDoc>

    <description xml:lang="en">

      This tModel defines the inquiry API calls for interacting with a V2 UDDI

      node.

    </description>

    <overviewURL>

      http://www.uddi.org/wsdl/inquire_v2.wsdl

    </overviewURL>

  </overviewDoc>

  <categoryBag>
    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="specification"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="xmlSpec"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"  

      keyName="types"

      keyValue="soapSpec"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"  

      keyName="types"

      keyValue="wsdlSpec"/>

   </categoryBag>

</tModel>

 

2.3.2 Messages covered

The UDDI messages covered by this tModel are:

  • find_binding: Used to locate specific bindings within a registered businessService. Returns a bindingDetail message.
  • find_business: Used to locate information about one or more businesses. Returns a businessList message.
  • find_relatedBusinesses: (UDDI V2 or later) Used to locate information about businessEntities that are related to a specific business entity whose key is passed in the inquiry. The relatedBusinesses feature was introduced in UDDI version 2 and is used to manage registration of business units and subsequently relate them based on organizational hierarchies or business partner relationships. Returns a relatedBusinesses message.
  • find_service: Used to locate specific services within a registered businessEntity. Returns a serviceList message.
  • find_tModel: Used to locate one or more tModel information structures. Returns a tModelList structure.
  • get_bindingDetail: Used to get full bindingTemplate information suitable for making one or more service requests. Returns a bindingDetail message.
  • get_businessDetail: Used to get the full businessEntity information for one or more businesses or organizations. Returns a businessDetail message.
  • get_businessDetailExt: Used to get extended businessEntity information. Returns a businessDetailExt message.
  • get_serviceDetail: Used to get full details for a given set of registered businessService date. Returns a serviceDetail message.
  • get_tModelDetail: Used to get full details for a given set of registered tModel data. Returns a tModelDetail message.

2.4 Example of Use

The following is a typical find_relatedBusinesses message using the version 2.0 UDDI inquiry tModel:

<find_relatedBusinesses generic="2.0" xmlns="urn:uddi-org:api_v2">

  <businessKey>BK1....</businessKey>

</find_relatedBusinesses>

3      UDDI Publication APIs (Version 1)

3.1 Introduction

This tModel is one of several tModels that collectively represent the UDDI programming interface for UDDI Version 1. The group of messages represented by this tModel deals with managing the information that is published in the registry. While a UDDI version 1 compliant registry is not required to have a node that provides a web service that implements this tModel, most do so as a standard means for providing the data on which the inquiry API is based. The uddi-org:publication_v2 tModel supercedes this tModel for version 2 compliant registries.

3.2 Design Goals

The design goal for the version 1.0 UDDI publication API is to provide a simple, complete set of messages publishers of registry entries use to publish UDDI registry entries.

3.3 tModel Definition

The details of the uddi-org:publication APIs are covered in the UDDI Programmer’s API Specification [3].

3.3.1 tModels:

Name: uddi-org:publication

Description: UDDI Publication API - Core Specification

tModel UUID: uuid:64C756D1-3374-4E00-AE83-EE12E38FAE63

Categorization: specification, xmlSpec, soapSpec, wsdlSpec

3.3.1.1 tModel Structure

<tModel tModelKey="uuid:64C756D1-3374-4E00-AE83-EE12E38FAE63">

  <name>uddi-org:publication</name>

  <description xml:lang="en">UDDI Publication API - Core Specification</description>

  <overviewDoc>

    <description xml:lang="en">

      This tModel defines the publication API calls for interacting with a

      V1 UDDI node.

    </description>

    <overviewURL>

      http://www.uddi.org/wsdl/publish_v1.wsdl

    </overviewURL>

  </overviewDoc>

  <categoryBag>
    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="specification"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="xmlSpec"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"  

      keyName="types"

      keyValue="soapSpec"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"  

      keyName="types"

      keyValue="wsdlSpec"/>

   </categoryBag>

</tModel>

 

3.3.2 Messages covered

The UDDI messages covered by this tModel are:

  • delete_binding: Used to remove an existing bindingTemplate from the bindingTemplates collection that is part of a specified businessService structure.
  • delete_business: Used to delete registered businessEntity information from the registry.
  • delete_service: Used to delete an existing businessService from the businessServices collection that is part of a specified businessEntity.
  • delete_tModel: Used to delete registered information about a tModel. If there are any references to a tModel when this call is made, the tModel will be marked deleted instead of being physically removed.
  • discard_authToken: Used to inform an Operator Site that a previously provided authentication token is no longer valid. See get_authToken.
  • get_authToken: Used to request an authentication token from an Operator Site. Authentication tokens are required to use all other API’s defined in the publishers API. This function serves as the programs equivalent of a login request.
  • get_registeredInfo: Used to request an abbreviated synopsis of all information currently managed by a given individual.
  • save_binding: Used to register new bindingTemplate information or update existing bindingTemplate information. Use this to control information about technical capabilities exposed by a registered business.
  • save_business:. Used to register new businessEntity information or update existing businessEntity information. Use this to control the overall information about the entire business. Of the save_x API’s this one has the broadest effect.
  • save_service: Used to register or update complete information about a businessService exposed by a specified businessEntity.
  • save_tModel: Used to register or update complete information about a tModel.

3.4 Example of Use

The following is a typical save_binding message using the version 1.0 UDDI publishing tModel:

<save_binding generic="1.0" xnkbs="urn:uddi-org:api">

  <authInfo>FFFFF</authInfo>

  <bindingTemplate>

    <description xml:lang="en">Publish to UDDI</description>

    <accessPoint URLType="https">https://...</accessPoint>

    <tModelInstanceDetails>

      <tModelInstanceInfo tModelKey="UUID:64C756D1-3374-4E00-AE83-EE12E38FAE63"/>

    </tModelInstanceDetails>

  </bindingTemplate>

</save_binding>

4      UDDI Publication APIs (Version 2)

4.1 Introduction

This tModel is one of several tModels that collectively represent the UDDI programming interface for UDDI Version 2. The group of messages represented by this tModel deals with managing the information that is published in the registry. While a UDDI Version 2 compliant registry is not required to have any of its nodes provide a web service that implements this tModel, most do so as a standard mechanism for providing the data on which the UDDI Inquiry API is based. This tModel supercedes the uddi-org:publication_v1 tModel.

4.2 Design Goals

The design goal for the version 2.0 UDDI publication API is to provide a simple, complete set of messages that publishers of registry entries can use to publish UDDI registry entries. The version 2.0 UDDI specification extends the version 1.0 specification for publication to meet several requirements not met by version 1. In particular it provides the ability to relate businessEntities to one another. In version 2, UDDI provides the ability for publishers to assert that a businessEntity they have published is related to another businessEntity. When the publishers of both businessEntities make the same assertion, a relationship is said to have formed. APIs have also been added to uddi-org:inquiry that allow UDDI users to search for related businessEntities.

4.3 tModel Definition

The details of the Version 2 Publication APIs are covered in the UDDI Version 2 API Specification [1].

4.3.1 tModels:

Name: uddi-org:publication_v2

Description: UDDI Publication API Version 2 - Core Specification

tModel UUID: uuid:A2F36B65-2D66-4088-ABC7-914D0E05EB9E

Categorization: specification, xmlSpec, soapSpec, wsdlSpec

4.3.1.1 tModel Structure

<tModel tModelKey="uuid:A2F36B65-2D66-4088-ABC7-914D0E05EB9E">

  <name>uddi-org:publication_v2</name>

  <description xml:lang="en">UDDI Publication API Version 2

      - Core Specification</description>

  <overviewDoc>

    <description xml:lang="en">

      This tModel defines the publication Version 2 API calls for interacting with a

      V2 UDDI node.

    </description>

    <overviewURL>

      http://www.uddi.org/wsdl/publish_v2.wsdl

    </overviewURL>

  </overviewDoc>

  <categoryBag>
    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="specification"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="xmlSpec"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"  

      keyName="types"

      keyValue="soapSpec"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"  

      keyName="types"

      keyValue="wsdlSpec"/>

   </categoryBag>

</tModel>

 

4.3.2 Messages covered

The UDDI messages covered by this tModel are:

  • add_publisherAssertions: (UDDI V2 or later) Used to add relationship assertions to the existing set of assertions. See the appendix describing relationship assertions.
  • delete_binding: Used to remove an existing bindingTemplate from the bindingTemplates collection that is part of a specified businessService structure.
  • delete_business: Used to delete registered businessEntity information from the registry.
  • delete_publisherAssertions: (UDDI V2 or later) Used to delete specific assertions from the assertion set managed by a particular publisher account. Only effects the relationship assertions specified, causing any relationships formed by virtue of a prior assertion to be invalidated.
  • delete_service: Used to delete an existing businessService from the businessServices collection that is part of a specified businessEntity.
  • delete_tModel: Used to hide registered information about a tModel. Any tModel hidden in this way is still usable for reference purposes, but is simply hidden from find_tModel result sets. There is no way to actually cause a tModel to be deleted, except by administrative petition.
  • discard_authToken: Used to inform an Operator Site that a previously provided authentication token is no longer required and should be considered not-valid if used after this message is received and until such time as an authToken value is recycled or reactivated at an operators discretion. See get_authToken.
  • get_assertionStatusReport: (UDDI V2 and later) used to get a list of relationship assertions that are useful for display in tools that help an administrator manage active and tentative assertions regarding relationships. Relationships are a feature introduced in generic 2.0 that help manage complex business structures that require more than one businessEntity or more than one publisher account to manage parts of a businessEntity. Returns an assertionStatusReport that includes the status of all assertions made involving any businessEntity controlled by the requesting publisher account.
  • get_authToken: Used to request an authentication token from an Operator Site. Authentication tokens are required to use all other API’s defined in the publishers API. This function serves as the programs equivalent of a login request.
  • get_publisherAssertions: (UDDI V2 and later) used to get a list of active relationship assertions that are controlled by an individual publisher account. Returns a publisherAssertions message containing a document that contains all relationship assertions associated with a specific publisher account.
  • get_registeredInfo: Used to request an abbreviated synopsis of all information currently managed by a given individual.
  • save_binding: Used to register new bindingTemplate information or update existing bindingTemplate information. Use this to control information about technical capabilities exposed by a registered business.
  • save_business: Used to register new businessEntity information or update existing businessEntity information. Use this to control the overall information about the entire business. Of the save_x API’s this one has the broadest effect. In UDDI V2, a feature is introduced where save_business can be used to reference a businessService that is parented by another businessEntity.
  • save_service: Used to register or update complete information about a businessService exposed by a specified businessEntity.
  • save_tModel: Used to register or update complete information about a tModel.
  • set_publisherAssertions: (UDDI V2 and later) -- used to save the complete set of relationship assertions for an individual publisher account. Replaces any existing assertions, and causes any old assertions that are not reasserted to be removed from the registry.

4.4 Example of Use

The following is a typical addPublisherAssertions message using the version 2.0 UDDI publishing tModel:

<addPublisherAssertions generic="2.0" xmlns="urn:uddi-org:api_v2">

  <authInfo>FFFF</authInfo>

  <publisherAssertion>

    <fromKey>BK1</fromKey>

    <toKey>BK2</toKey>

    <keyedReference tModelKey="uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03"

      keyName="Holding Company" keyValue="parent-child"/>

  </publisherAssertions>

</addPublisherAssertions>

5      UDDI Taxonomy API (Version 1)

5.1 Introduction

This tModel is one of several tModels that collectively represent the UDDI programming interface for UDDI V1. This tModel was never used and has been superceded by uddi-org:taxonomy_v2.

5.2 Design Goals

The design goal for the version 1.0 UDDI taxonomy API is to provide a simple interface to enable the keyValues in keyedReferences to be validated by the providers of taxonomies.

5.3 tModel Definition

The details of the version 1.0 uddi-org:taxonomy API are covered in the UDDI Programmer’s API Specification [3].

5.3.1 tModel

Name: uddi-org:taxonomy

Description: UDDI Taxonomy API - Core Specification

tModel UUID: uuid:3FB66FB7-5FC3-462F-A351-C140D9BD8304

Categorization: specification, xmlSpec, soapSpec

5.3.1.1 tModel Structure

<tModel tModelKey="uuid:3FB66FB7-5FC3-462F-A351-C140D9BD8304">

  <name>uddi-org:taxonomy</name>

  <description xml:lang="en">UDDI Taxonomy API - Core Specification</description>

  <overviewDoc>

    <description xml:lang="en">

      This tModel defines the taxonomy maintenance API calls for interacting with the

      UDDI registry.

    </description>

    <overviewURL>

      http://www.uddi.org/taxonomies/UDDI_Registry_tModels.htm#TaxV1

    </overviewURL>

  </overviewDoc>

  <categoryBag>
    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="specification"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="xmlSpec"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"  

      keyName="types"

      keyValue="soapSpec"/>

   </categoryBag>

</tModel>

 

5.3.2 Messages Covered

The UDDI version 1 taxonomy API consists of a single message

  • validate_categorization: The validate_categorization service performs two functions. It is used to verify that a specific category (keyValue) exists within the given taxonomy. The service also optionally restricts the entities that may be classified within the category.

6      UDDI Taxonomy API (Version 2)

6.1 Introduction

This tModel is one of several tModels that collectively represent the UDDI programming interface for UDDI V2. The message represented by this tModel deals with validating how publishers use categorizations and identifiers to describe their businessEntities, businessServices, and tModels.

6.2 Design Goals

The design goal for the version 2.0 UDDI Taxonomy API is to define a simple interface required to validate that the use of validated categorization and identification systems conforms to the usage defined by each system's provider. The usage restrictions may vary from simple to complex. A common, simple example is insisting that the keyValues in keyedReferences come from a well-defined set. At the other extreme, a categorization or identification system provider may restrict the use of some or all of its values to classifying the businessEntities of members of a particular organization or to those with which it has a reciprocal business relationship.

6.3 tModel Definition

The details of the Version 2.0 Taxonomy API are covered in the UDDI Version 2 API Specification [1].

6.3.1 tModel

Name: uddi-org:taxonomy_v2

Description: UDDI Taxonomy API Version 2 - Core Specification

tModel UUID: uuid:1E3E9CBC-F8CE-41ab-8F99-88326BAD324A

Categorization: specification, xmlSpec, soapSpec

6.3.1.1 tModel Structure

<tModel tModelKey="uuid:1E3E9CBC-F8CE-41ab-8F99-88326BAD324A">

  <name>uddi-org:taxonomy_v2</name>

  <description xml:lang="en">UDDI Taxonomy API Version 2

      - Core Specification</description>

  <overviewDoc>

    <description xml:lang="en">

      This tModel defines the taxonomy validation API calls for interacting

      with a V2 UDDI node.

    </description>

    <overviewURL>

      http://www.uddi.org/taxonomies/UDDI_Registry_tModels.htm#TaxV2

    </overviewURL>

  </overviewDoc>

  <categoryBag>
    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="specification"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

      keyName="types"

      keyValue="xmlSpec"/>

    <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"  

      keyName="types"

      keyValue="soapSpec"/>

   </categoryBag>

</tModel>

 

6.3.2 Messages Covered

The UDDI version 2 Taxonomy API consists of a single message:

  • validate_values: A UDDI operator sends the validate_values message to the appropriate external validation service whenever a publisher saves data that uses a categorization value or identifier whose use is regulated by the external party who controls that service. The normal use is to verify that specific categories or identifiers (keyValues) exist within the given classification or identification system. For certain categorizations and identifiers, the party providing the validation service may further restrict the use of a value to certain parties based on other information known about the publisher or passed in the message.

6.4 Example of Use

The complete process a classification or identifier system provider must follow to publish and activate a checked taxonomy or identifier system is detailed in [4].

7      References

[1] "UDDI Version 2.0 API Specification", http://uddi.org/pubs/ProgrammersAPI_v2.htm

[2] "UDDI 2.0 Data Structure Reference", http://www.uddi.org/pubs/DataStructure_v2.htm

[3] "UDDI Programmer's API 1.0", http://uddi.org/pubs/ProgrammersAPI-V1.01-Published-20020628.pdf

[4] "Providing a Taxonomy for Use in UDDI Version 2", http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-taxonomy-provider-v100-20010717.htm

 

Notices

These UDDI Specifications (the "Documents") are provided by the companies named above ("Licensors") under the following license.  By using and/or copying this Document, or the Document from which this statement is linked, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions:

 

Permission to copy, prepare derivative works based on, and distribute the contents of this Document, or the Document from which this statement is linked, and derivative works thereof, in any medium for any purpose and without fee or royalty under copyrights is hereby granted, provided that you include the following on ALL copies of the document, or portions thereof, that you use:

1.                   A link to the original document posted on uddi.org.

2.                   An attribution statement : "Copyright © 2000 - 2002 by Accenture, Ariba, Inc., Commerce One, Inc. Fujitsu Limited, Hewlett-Packard Company, i2 Technologies, Inc., Intel Corporation, International Business Machines Corporation,  Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc., and VeriSign, Inc.  All Rights Reserved."

If the Licensors own any patents or patent applications that may be required for implementing and using the specifications contained in the Document in products that comply with the specifications, upon written request, a non-exclusive license under such patents shall be granted on reasonable and non-discriminatory terms. 

 

EXCEPT TO THE EXTENT PROHIBITED BY LOCAL LAW, THIS DOCUMENT (OR THE DOCUMENT TO WHICH THIS STATEMENT IS LINKED) IS PROVIDED "AS IS," AND LICENSORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY OF THE INFORMATIONAL CONTENT, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY OR (WITH THE EXCEPTION OF THE RELEVANT PATENT LICENSE RIGHTS ACTUALLY GRANTED UNDER THE PRIOR PARAGRAPH) LICENSOR PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. Some jurisdictions do not allow exclusions of implied warranties or conditions, so the above exclusion may not apply to you to the extent prohibited by local laws. You may have other rights that vary from country to country, state to state, or province to province.

 

EXCEPT TO THE EXTENT PROHIBITED BY LOCAL LAW, LICENSORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL DAMAGES, OR OTHER DAMAGES (INCLUDING LOST PROFIT, LOST DATA, OR DOWNTIME COSTS), ARISING OUT OF ANY USE, INABILITY TO USE, OR THE RESULTS OF USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF, WHETHER BASED IN WARRANTY, CONTRACT, TORT, OR OTHER LEGAL THEORY, AND WHETHER OR NOT ANY LICENSOR WAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Some jurisdictions do not allow the exclusion or limitation of liability for incidental or consequential damages, so the above limitation may not apply to you to the extent prohibited by local laws.

 

Copyright  © OASIS Open 2002. All Rights Reserved.

 

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

 

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

 

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

 

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

 

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.