[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Groups - Strawman Proposal - Representing Property Information (uddi-spec-tc-proposal-strawman-representing-property-information-20050320.doc) uploaded
Hi Jin & Luc, Regarding the discussion of keyedReferenceGroup validation in item 2 below, I'd prefer to use means provided by the UDDI 3.0 specification itself. Section 5.2.3 (Special considerations for validated value sets) says that the category group system tModel needs to specify the category group systems whose keys are allowed to occur in corresponding keyedReferenceGroup/keyedReference elements. I agree with Luc that this feature may be somewhat underspecified, but I'd prefer to have a canonical solution as part of the specification rather than a TN, which is always optional. Claus -----Original Message----- From: Tong Jin [mailto:tong_jin@bah.com] Sent: Mittwoch, 30. März 2005 18:11 To: luc.clement@systinet.com; uddi-spec@lists.oasis-open.org Subject: RE: [uddi-spec] Groups - Strawman Proposal - Representing Property Information (uddi-spec-tc-proposal-strawman-representing-property-information-20050320.doc) uploaded Luc/Group, Here are my comments: 1. General I agree with the general approach in laying out a set of guidelines and usage patterns in capturing property meta data for UDDI entities. Further, I agree to expand the formalism of doing so into a UDDI technical note. 2. Technical I would recommend capturing the relationship between the tModel definitions for each property (name, email, dn, etc) with the its enclosing categorizationGroup tModel. The purpose is to give some hint/guidelines as to how to use the categorizationGroup, what can go in such a keyedReferenceGroup. Furthermore, user interfaces (and tooling) can use such meta data to do validation. One way this can be implemented is to use categorization on the categorizationGroup tModel definition to include keyedReferences to the set of property tModel keys as keyValues, using keyNames to hold property names/comments. We may need to define a special tModel for the key of such keyedReferences. This approach is similar to what is in the "Property In UDDI" proposal in [1]. 3. Editorial * Page 3, line 111 "... The xxx-org:yy...servicetype" category system will be used for this purpose." You probably meant the categorizationGroup tModel "xxx-org:organizationalContact". * Page 7 to page 8, section "Representing Contact Relationships" The introduction and definition of "uddi:xxxx:org:yyyy:2005:03:relations:contact" categorization system seems to trump previous mentions of "uddi:xxx-org:property:contact:relationship" categorization system (see the first keyedReference in the "organizationalcontact" keyedReferenceGroup in "all" examples.) Did you mean to define the same categorization system? * Page 8, line 312-313 Where did the XXXX:BrokeredServicesITService (categorization) come from and where was it used? * Throughout the document, the naming and UDDI keys of all the relevant tModels need to be consistent, for example, search and replace all "xxx" with "xxxx". [1] http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/1160 2/uddi-spec-tc-prop030-property-and-significant-keyname-20050225.doc Jin Tong ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Phone 703-917-2839 || Booz | Allen | Hamilton Fax 703-902-3457 || 8251 Greensboro Drive Email Tong_Jin@bah.com || McLean VA 22102 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -----Original Message----- > From: luc.clement@systinet.com [mailto:luc.clement@systinet.com] > Sent: Sunday, March 20, 2005 3:56 PM > To: uddi-spec@lists.oasis-open.org > Subject: [uddi-spec] Groups - Strawman Proposal - > Representing Property Information > (uddi-spec-tc-proposal-strawman-representing-property-informat ion-20050320.doc) uploaded > > The document named Strawman Proposal - Representing Property > Information > (uddi-spec-tc-proposal-strawman-representing-property-informat ion-20050320.doc) > has been submitted by Luc Clement to the OASIS UDDI > Specification TC document repository. > > Document Description: > This document describes how to represent property information > in registry. > Specifically, it describes how to represent contacts and > their relationship with entities. > The problem and the motivating use cases are described at [1] > and [2]. In addition to these at numerous other occasions the > author has been asked and has worked with vendors and > practitioners to address this specific need. > What is required in essence is agreement on the methodology > to use to describe property information. This document does > so using an example specifically, the representation of > contact information associated with an entity of the UDDI data model. > [1] > http://lists.oasis-open.org/archives/uddi-spec/200503/msg00005.html > [2] > http://lists.oasis-open.org/archives/uddi-dev/200503/msg00001.html > > > View Document Details: > http://www.oasis-open.org/apps/org/workgroup/uddi-spec/documen > t.php?document_id=11942 > > Download Document: > http://www.oasis-open.org/apps/org/workgroup/uddi-spec/downloa d.php/11942/uddi-spec-tc-proposal-strawman-representing-property-> information-20050320.doc > > > PLEASE NOTE: If the above links do not work for you, your > email application may be breaking the link into two pieces. > You may be able to copy and paste the entire link address > into the address field of your web browser. > > -OASIS Open Administration > --------------------------------------------------------------------- To unsubscribe, e-mail: uddi-spec-unsubscribe@lists.oasis-open.org For additional commands, e-mail: uddi-spec-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]