[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Assistance please - FW: ebXML TC review and input of the UDDI Spec TC "UDDI as the registry for ebXML components"
Reason: Delivery not authorized
The sender is not authorized to send to the destination.
To: OASIS ebXML Joint Committee Chair, Dale Moberg dmoberg@cyclonecommerce.com
Cc:
References:
[1] UDDI as the registry for ebXML components, UDDI Spec TC Technical Note, http://www.oasis-open.org/committees/uddi-spec/doc/draft/uddi-spec-tc-tn-uddi-ebxml-20030508.htm
[2] UDDI Spec TC Process, http://www.oasis-open.org/committees/uddi-spec/doc/process/uddi-spec-tc-process-20021212.htm.
Dale,
I'm writing to you as Chair of the ebXML JC for the purpose of obtaining your and other ebXML TC chair's support for final review and input of the UDDI Spec TC's "UDDI as the registry for ebXML components" [1] Technical Note (TN). As you may know, the UDDI Spec TC has approved this document as a Committee Technical Note in accordance with its TC process which you can find in Section 2 of [2].
Acting on the UDDI Spec TC's behalf,
Paul Macias approached the CPPA and Messaging TCs
in March of this year with a request for review and input on the portions of the
TN that involve aspects of the CPPA and MS specifications referenced by the
Technical Note. You agreed as Chair of the CPPA TC to present this TN to your TC
for review at your TC's 27 March telecon. Paul did not get a response from the
Messaging TC. Unfortunately, we did not obtain comments back resulting from this
request, and thus decided to move forward for approval of the TN. I'm pleased to
note though, that the ebXML RegRep TC has recently provided comment on the TN
which we will consider during our 8 Jul
telecon.
The TN has now been approved and ready
to be posted pending finalization of names, URLs and keyspaces referring to
ebXML components, and consideration of further comments we may receive as part
of this activity. While the UDDI Spec TC could make such assignments and derive
these from its namespace, we feel it more appropriate for these to be derived
from those already defined by the ebXML community. Furthermore, we also think
that these should be managed by ebXML rather than
UDDI.
We ask your support in your capacity as
Chair of the ebXML JC in coordinating the necessary activities allowing for the
following:
a. obtain review of the
TN
b. assign or confirm the
appropriateness of the current assignments of the
following:
· tModel Names (e.g. ebxml-org:specifications)
· overview document URLs used to point to ebXML specifications (e.g. http://www.ebxml.org/specs/index.htm)
· keyspace used for UDDI v3 tModel keys (e.g. uddi:ebxml.org:specifications)
Note 1: I've provided an excerpt below to demonstrate by way of example what we are asking of ebXML TCs. I've put in yellow highlight examples of tModel names, URLs and v3 keys we seek input on.
Note 2: v1 and v2 format key derivation (by way of UDDI v3's key hashing algorithm) will be performed after we finalize the tModel keys to be assigned
If, as a conclusion of your review, you would prefer for these names and keyspaces to be assigned by the UDDI TC within its own namespace, please let Tom and I know and we will do so.
c. identify the timeframe for completion of this review
We want to finalize and post this TN as soon as possible given its approval by the TC, but will gladly delay this allowing for input from ebXML TCs.
Please let me know your thoughts at the earliest possible convenience. If it would help, I'll gladly arrange for a telecon to discuss this with you and the other chairs.
Thanks in advance for your time and consideration of this matter.
Luc
Clément
Microsoft
Co-chair, OASIS UDDI Spec TC
Excerpt from [1]
2.2.3 ebXML
Specifications Taxonomy tModel
ebXML is a framework that consists of
several distinct technical specifications, each of which must be represented by
tModels in a UDDI registry. UDDI tModels are usually tagged with categorizations
denoting information that facilitates their discovery. That is why before
defining tModels representing ebXML specifications, we define an ebXML
Specifications Taxonomy tModel, which is used to categorize these tModels
(described in the following section).
ebXML Specification Taxonomy tModel:
tModel
Name:
ebxml-org:specifications
tModel Description:
ebXML Specifications Taxonomy
tModel UDDI Key (V3):
uddi:ebxml.org:specifications
Derived V1, V2 format Key:
uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx01 (to be
derived)
Categorization:
categorization
Checked:
No
<tModel
tModelKey="uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx01">
<name>ebxml-org:specifications</name>
<description
xml:lang="en">ebXML Specifications
Taxonomy</description>
<overviewDoc>
<overviewURL>http://www.ebxml.org/specs/index.htm</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:C1
keyName="uddi-org:types"
keyValue="categorization"
/>
<keyedReference
tModelKey="uuid:C1
keyName="uddi-org:types"
keyValue="unchecked"
/>
</categoryBag>
</tModel>
The following values are defined for
this ebXML Specifications taxonomy. These values are useful for classifying
ebXML-related tModels and are helpful for others who want to find those
tModels.
ebXML:CPPA ebXML Collaboration Protocol Profile and
Agreement
ebXML:MS ebXML Message
Service
ebXML:BPSS ebXML Business Process Specification
Schema
Please note that this tModel is a
categorization system for ebXML framework specifications and does not represent
ebXML specifications themselves.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]