Member Name	Company or Organization	2/10-12/2004 FTF
Atkinson, Bob	Microsoft
Bellwood, Tom	IBM	y
Blum, Adam	Systinet	y
Cahuzac, Maud	France Telecom	y
Clement, Luc	Individual	y
Colgrave, John	IBM
Corda, Dr. Ugo	SeeBeyond Technology
Dovey, Matthew	Individual
Feygin, Daniel	Unitspace	y
Garg, Shishir	France Telecom
Hately, Andrew	IBM	y
Henry, Brad A.	Individual
Kawai, Aikichi	NTT
Kochman, Rob	Microsoft	y
Macias, Paul A.	LMI	y
Morgenthal, JP	Software AG	y
Nishikawa, Mary (Leave of absence)	Individual
Novotny, Mirek	Systinet	y
Paolucci, Massimo	Individual
Rogers, Tony	Computer Associates	y
Sycara, Katia	Individual
Thomas Manes, Anne	Individual
Thorpe, Paul	OSS Nokalva
von Riegen, Claus	SAP AG
Voskob, Max	Individual
Wu, Zhe	Oracle
Zagelow, George	IBM

Also in attendance were:

· Mike De Nicola, Fujitsu who joined the TC for the duration of the FTF

· George Zagelow, IBM and Eric Hammer, Intel who joined the TC on Wed for the Steering Committee agenda item.

· Fred Carter, Amberpoint who co-submitted with Adam Blum, Systinet a proposal [1, 2] for a technical note describing how to store web services management information in UDDI, joined the TC Wed afternoon for discussion of the proposal.

2 Additions to Agenda

No new agenda items were proposed.

3 Approval of Previous Minutes

Motion:

Motion to approve the minutes of the 20040127 meeting, which are posted at: http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5286/TCMinutes-V1.1-20040127.doc

Minutes:

The minutes were approved.

4 Schedule for FTF Meeting by Day

Approximate timing for FTF sessions is provided below. We split in two teams to work on the following topics:

1. Group A: Access Control, WS-Security, Trustworthiness, Contacts Element Enhancements

· Daniel Feygin, Unitspace (split participation)

· Andrew Hately, IBM

· Rob Kochman, Microsoft

· Mirek Novotny, Systinet

· Tony Rogers, Computer Associates

2. Group B: Taxonomy Mgmt, Inquiry Enhancements, Grid

· Tom Bellwood, IBM

· Adam Blum, Systinet

· Maud Cahuzac, France Telecom

· Luc Clément

· Daniel Feygin, Unitspace (split participation)

· Paul Macias, LMI

· JP Morgenthal, Software AG

Day	Item
Tuesday
	Open Meeting & Take Attendance	10:00	-	10:15
	Administrative Items	10:15	-	10:30
	Review AR List	10:30	-	10:45
	Review Change Requests	10:45	-	12:00
	LUNCH	12:00	-	13:00
	Review “V3 Issue: discoveryURL & overviewURL” item	13:00	-	13:30
	Discuss breakout assignments & work product goals	13:30	-	13:45
	Breakout Session – Group A – REQ 4 & 16	13:45	-	15:00
	Breakout Session – Group B – REQ 23	13:45	-	15:00
	Afternoon Break	15:00	-	15:30
	Breakout Session – Group A - REQ 16 & 18	15:30	-	17:00
	Breakout Session – Group B – REQ 23 & 20	15:30	-	17:00
	Review Progress from Groups A & B / Adjust Schedule	17:00	-	17:30

Wednesday
	Breakout Session – Group A - REQ 27	9:45	-	12:00
	Breakout Session – Group B – REQ 11-14	9:45	-	12:00
	LUNCH	12:00	-	13:00
	Discussion & Report from Steering Committee	13:00	-	14:00
	Discussion & Report from Demo Subcommittee	14:00	-	14:30
	“Representing Web Services Management Information in UDDI” TN Proposal	15:00	-	17:00

Thursday
	Both groups – REQ 28 and 29	9:00	-	12:00
	LUNCH	12:00	-	13:00
	Both groups – REQ 28 and 29	13:00	-	14:30
	Afternoon Break	14:30	-	15:00
	Group Discussion – Review of Progress from Groups A & B	15:00	-	17:00
	Adjourn	17:00

5 Old Business

5.1 Administrative Items

5.1.1 New Zealand FTF

Our next FTF is scheduled for Tuesday, 30 March through Thursday, 1 April. A 4th day on Friday, 2 April is also planned, although this day is optional and intended for sub-groups to continue working on any items necessary.

As an individual member, Max is hosting this event for us. We do need to discuss the venue though and potentially options for funding it. We have two venue options:

1. Pick a hotel in Wellington and meet there

2. The Brackenridge in Martinborough (www.Brackenridge.co.nz)

If we go with option 1 then the facilities will be typical hotel fare. Cost is likely relatively low though. If we pick option 2, it appears this would be a much better place to meet and would keep us focused, but the expense is $350/day. If we decide to go this way, we can take it to the SC meeting happening this week. Another alternative for location 2 is for us to all kick in and cut the cost that way.

TC to discuss the alternatives, including the option of requesting SC funds to cover the meeting cost, as we have plenty in our account to easily accommodate this. We should try to settle on the venue during this FTF so that people can complete their bookings.

Minutes

Tom presented the options and discussed the possibility of requesting funding from the Steering Committee to cover the cost of facilities.

We chose the Brackenridge location, and agreed to request funding from the SC.

5.2 Review of AR List

5.2.1 Update to the “Key Partitions” TN - AR 0002

Update Key Partitions TN

Andrew Hately

Open

2 Dec 2003

Andrew to present on progress.

Minutes:

Andrew did not post the document in time for the TC to review. This AR was tabled for the next telecon.

5.2.2 tModel overviewDocument template – AR 017

Value set tModel overvie...nce document

Max Voskob

Open

11 Oct 2003

Current status:

a. Done - Tony to confirm Luc’s updates are OK

b. Done - Luc to produce HTM/PDF versions

c. Max to produce and TC to review the template

d. TC to vote on the template and TN

e. Luc to post each to UDDI.org

Review posting from Max (was due week of 2/1) of the templates and the TN

Minutes:

· Currently waiting for Max to submit a template for the tModel overview documents.

· Luc to remind Max for the need of this template so we can resolve this item.

· Further discussion on this AR was tabled to the next telecom.

5.2.3 Publish TC published tModels to UBR - AR 022

Publish TC published tModels to UBR

Luc Clement

Open

10 Feb 2004

Minutes

Luc has completed the list of tModels to be published to the http://uddi.org/tmodels.html, though prior to the FTF there were open issues that needed to be addressed (see [3, 4, 5]).

Luc also prepared files containing the XML definitions required for the publication of the v2 and corresponding v3 tModels at a UBR node. IBM will be hosting these tModels on its UBR node. The creation of the v3 and keyPartition tModels will be handled separately from the publication of v2 tModels. Two source files have been created: one with v2 tModels; and a 2^nd file containing the details of the v3 tModels and the associated keyPartitions tModels.

A discussion of open issues follows:

a. Creation of Key Partitions

Background

Andrew brought up the point that key partitions are required to support some of the tModels identified by [6]. The following v3 keyGenerator tModels need to be published at a UBR node:

uddi:ebxml.org:keygenerator
uddi:ebxml.org:collaborationprotocolagreement:keygenerator
uddi:ebxml.org:collaborationprotocolagreement:v1.0:keygenerator
uddi:ebxml.org:collaborationprotocolagreement:v2.0:keygenerator
uddi:ebxml.org:collaborationprotocolprofile
uddi:ebxml.org:messageservice
uddi:uddi.org:wsdl
uddi:uddi.org:wsdl:categorization
uddi:uddi.org:xml
uddi:untmg.org
uddi:untmg.org:businessprocessspecificationschema

Luc and Andrew were to take the discussion off-line.

Discussion

The keyGenerator tModels were defined along with the v3 version of the tModels concerned, though a separate issue was identified: digital signature of the keyPartition tModels.

We discussed the possible additional need to digitally sign keyPartition tModels given UBR policy. The digital signature requirement would impose the need for the TC to obtain a certificate. Further consideration also needs to be given for the case of the untmg.org and ebxml.org domains given their key generators fall outside of the uddi.org domain name.

We concluded that we need to discuss this matter further with the UBR Operators Council, and agreed to defer this discussion to later when the UBR migrates up to v3.

b. Adding a section specifying the keyGenerator associated with the key space for which a given tModel’s key lies within

Background

Andrew pointed out that we should specify with each v3 tModel the keyGenerator tModel associated with the key space that the tModel lies within. We discussed adding an additional section to the http://uddi.org/tmodels.html page proposed at [6] for each tModel. Luc was to retrofit to the document.

Discussion

After further consideration, Luc commented that this was not required; all agreed.

c. Open issue with the WSDL Address tModel

Background

Luc pointed out at [4] a discrepancy of the modeling used for the WSDL Address tModel in section 2.5.2 of the “Using WSDL in a UDDI Registry, v2”. At issue is an incomplete mapping.

Luc proposed either to remove section 2.5.2 – Optional Extensions or updating the TN whereby the bindingTemplate would also need to be categorized with a reference to the "WSDL Address" tModel; if adopted there would be two requisite changes to be made to the WSDL Address tModel (Section B.9.1):

a. it needs to be changed to a "categorization" tModel; and

b. a valid value (Section B.9.3) needs to be assigned (i.e. wsdl:address or something like that).

Discussion

As discussed below in Section 2.5.2 of these minutes, we agreed to remove Section 2.5.2 – Optional Extensions of the “Using WSDL in a UDDI Registry, v2” TN. Doing so addresses the issue brought up and no longer requires the WSDL Address tModel to be modified.

Based on the outcome of the discussion, per AR-0022 Luc is now in a position to submit the v2 tModel definition XML file to IBM for publication. (At the time of this writing, this has been submitted to Andrew Hately, IBM for publication).

Once published at the IBM UBR Node, per AR-0024 Luc is to submit the updates to the http://uddi.org/tmodels.html to the Member Section’s Steering Committee.

5.3 Technical Notes

5.3.1 Proposed Errata – “UDDI as the registry for ebXML Components” TN

Discussion of the proposed errata to the “UDDI as the registry for ebXML Components” TN per [3].

Minutes:

Per [3] the “UDDI as the registry for ebXML Components” TN has some typo; the URLs to some overview documents have changed; and we need to point the ebXML Specifications Taxonomy tModel's overviewURL to the TN rather that the ebXML's TC page.

NEW AR: AR-0023 Daniel to update the TN. (As of the time of this writing, this AR has been completed).

5.3.2 Proposed Errata – “Using WSDL in a UDDI Registry, v2” TN

Discussion of the propose errata to the “Using WSDL in a UDDI Registry, v2” TN per [4] and [5]:

Minutes:

Luc discovered a number of “inconsistencies” ([4, 5]) in the text of the TN when compared to the tModel definitions themselves. John Colgrave has suggested we just publish on the UBR and use that as the normative version. Luc felt that the TN should be the authoritative source, not the UBR, so he wants to see the TN fixed.

The changes we agreed to make to the TN are as follows:

1. many tModels are missing the "description" element in the XML rendering of the tModel's structure (e.g. B.3.2.1 V2 tModel Structure). These are to be made consistent with the XML provided by Luc.

2. there is inconsistent use of keyName attributes: some use "types" as the string and others are missing the keyName. In the attached, I've updated the tModels to use "uddi-org:types" as the keyName value and have added missing keynames. These are to be made consistent with the XML provided by Luc.

Discussion of Section’s 2.5.2 Optional Extensions. According to Luc, the WSDL Address tModel is missing from the list of mapping in item 2 of section 2.5.2; without it the mapping of optional extensions is incomplete. John Colgrave suggested that rather than enhancing section 2.5.2 we should remove this section from the TN so that there is consistent treatment for both V2 and V3 clients. Luc agreed to this.

Systinet has already implemented this TN, but does not have an issue with the removal of section 2.5.2 since it uses the V2 approach.

Over time Luc would like to see us adopt the mapping currently proposed in section 2.5.2 (with the necessary changes to the WSDL Address tModel) exploiting v3’s bindingTemplate categoryBag in the mapping.

The TC agreed to the removal of the optional extensions described in section 2.5.2 of the TN.

NEW AR: AR-0025 Tony Rogers assigned to update the TN to match the above corrections Luc has made in the tModels being published. The TC has determined that the TN must be the authoritative source.

5.4 Change Requests

5.4.1 CR053 – Change to keyGenerator categorizations

CR #	Document Identifier	Title / Action	Authors
CR-053	http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5156/uddi-spec-tc-cr053-keyGeneratorCategorizationRestrictions-20040126.doc	Change to keyGenerator categorizations	Andrew Hately

At the 20040127 telecon, Claus presented the CR but did mention that there are open issues brought up by John’s mail (refer to http://lists.oasis-open.org/archives/uddi-spec/200401/msg00110.html). Claus suggested that we need another round of discussion on this before we can close on the CR; John will work with Claus on this.

Discussion deferred to the 20040302 telecon.

Minutes:

Although Claus was unable to be present, TC discussed this item. This CR discusses the use of the keyGenerator categorization defined by the uddi.org:categorization:types value set. At issue is that if you specify this categorization on a tModel, you create a keyGenerator. However, there is no behavior listed if you were to save it on a bindingTemplate, for example. The intent is that it only has behavior when it’s specified for a tModel, but it’s not explicitly said in the spec. There are two issues:

1. All keyGenerator tModels must be categorized as shown.

2. Only keyGenerator tModels may be categorized as shown.

3. It is impossible to create a keyGenerator tModel with a UDDI V2 API call.

Luc would prefer that we not update the behavior sections, and just define the valid usage in Ch. 11 so we don’t have to sprinkle explanations everywhere.

The last clarification is that an error is produced if you try to update a non-tModel entity with this classification. (E_valueNotAllowed). This needs to be described in the categorizationTypes tModel definition (Ch.11.1.1.4 Valid Values) too. Tony would like the table in this section to indicate “Special Treatment” and have an explanation for its use following the table.

The TC decided that the specification will not restrict the entirety of the value set specifically to tModels due to migration concerns and the need support the wsdlDeployment value which represents the sole exception.

While we agreed that allowing keyGenerator in V2 might save implementation costs, we also agreed it would be the wrong thing to do, and thus, the CR needs to address this issue.

A further change suggested by John was that we should make a clearer separation between the “create” and “update” cases.

NEW AR: AR-0026 - Claus to resubmit the CR with these changes made.

5.4.2 CR054 – Processing of changeRecordNewDataConditional with Multiple Collisions and Node Status Changes

CR #	Document Identifier	Title / Action	Authors
CR-054	http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5397/uddi-spec-tc-cr054-uddi_v3replication.xsd	Processing of changeRecordNewDataConditional with Multiple Collisions and Node Status Changes	Andrew Hately

This CR introduces changeRecordConditionFailed to deal with collision detection problems caused by each node tracking the success or failure of data in changeRecordNewDataConditional.

Minutes:

Andrew took us through the details of this CR. If one saves one conditional tModel at multiple nodes, there is a case where it does not properly persist. Please see the CR for full details. Since we allow publishers pick their own keys, we need a negotiation mechanism in multi-node implementations. There are 2 cases that will fail:

1. 3 or more collisions by saving same thing at 3 nodes.

2. If you change the number of nodes in a registry while a conditional save is in progress, there is either a stalemate or premature confirmation given.

The core issue is that we allow a pseudo 2-phase commit that permits race conditions to occur. The current algorithm is flawed and needs to be corrected. What is proposed is that the data originator now issues an acknowledgement once it’s seen all the others. This moves the tracking of success back to the node that produced the record in the first place.

The CR does a complete replacement of the text in the specification.

There is also a replication schema change document which supports this CR.

Motion to approve this CR for the v3.0.2 bucket: Approved.

5.4.3 CR055 – Response to Evolved tModels

CR #	Document Identifier	Title / Action	Authors
CR-055	http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5398/uddi-spec-tc-cr055-responseForEvolvedtModels.doc	Response to Evolved tModels	Andrew Hately

Each tModel should only need to be stored once in the data model. The tModel returned in response to a V2 inquiry issued to a multi-version V3 registry should be based on the v3 canonical/bootstrap tModels.

The V2 tModels for transports and taxonomies have been “evolved” into the V3 specification and the V3 UBR Value Set tModels documentation. It is necessary to specify the expected response to the V2 inquiries to the canonical and bootstrap tModels.

Minutes:

There are tModels in V2 which are evolved to V3, however, there are some subtle differences such as containing V3 URLs, and so if you made a v2 request you wouldn’t get exactly what is specified in the v2 spec. The specification is silent on this. These affect the overviewURL element. This CR defines all of the overviewURLs that will be returned for V2 inquiries, even though they are V3 references.

The second difference is that V3 tModels include references in the uddi-org:types taxonomy that are new for V3 (e.g., cacheable). The CR documents that V2 inquirers should expect that v3 values will be returned where applicable, even though they are V3 specific.

Motion to approve this CR for the v3.0.2 bucket: Approved.

5.4.4 CR056 – Custody Transfer API in Wrong Namespace

CR #

Document Identifier

Title / Action

Authors

CR-056

http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5399/uddi-spec-tc-cr056-custodyTransferInWrongNamespace.doc

http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5400/uddi-spec-tc-cr056-schemaWSDL.zip

Custody Transfer API is in the wrong namespace.

Andrew Hately

The transfer_custody API is intended as a node to node but is currently in the same binding as the client/user APIs for custody transfer. This makes it difficult to secure using SSL with mutual authentication the API as recommended

Minutes:

When multiple nodes are involved, there is an API called transfer_custody that adjudicates between the nodes, and depends upon a trusted relationship between the nodes. This is not a user facing API, even though it’s documented in that namespace. This makes it hard to implement a different security policy for use of this API. This CR changes the namespace to the replication namespace to make that possible. This update is proposed for 4.1.1 transfer_custody (adds one sentence). The other changes are in the schemas and WSDLs.

See the schema files posted at http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5400/uddi-spec-tc-cr056-schemaWSDL.zip.

Motion to approve this CR for the v3.0.2 bucket: Approved.

5.4.5 CR057 – Version Specific Publication Behavior

CR #	Document Identifier	Title / Action	Authors
CR-057	http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5420/uddi-spec-tc-cr057-versionSpecificPublicationBehavior.doc	Version Specific Publication Behavior	Andrew Hately

Section 10.3 of the specification currently addresses data migration between Version 2 and Version 3; however, the behavior specified should be extended to apply for publication in general as well.

Minutes:

This item was posted on behalf of Microsoft. Ch. 10 discusses migration of data, but the considerations there also apply to publication of data. This CR reorganizes the material into Publish Considerations and Data Migration Considerations. The change mostly just renames the headers.

The CR also clarifies what’s meant by pruning empty containers.

Tony also wants the document block to indicate that we’re talking about V2 messages going to a “multi-version” V3 node, not just a “V3 node”. This update was made and the change resubmitted.

Motion to approve this CR for the v3.0.2 bucket: Approved.

5.4.6 CR058 – URLType and useType Mapping

CR #	Document Identifier	Title / Action	Authors
CR-058	http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5402/uddi-spec-tc-cr058-URLTypeAndUseTypeMapping.doc	URLType and useType Mapping	Andrew Hately

Here is the scenario:

· A bindingTemplate is saved in v2 on node 1 with an accessPoint adorned with the attribute URLType="phone".

· Node 2 replicates from Node 1 with a v3_getChangeRecords.

· Node 1 then sends a v3 changeRecordNewData containing the bindingTemplate.

· As a result, at some point the bindingTemplate must be converted in v3 in the changeRecordNewData including this attribute. The specs state that URLType="phone" must be converted into useType="endPoint".

· If so, Node 2 loses information ("phone") but if Node 1 allows the value to be set to "phone", then we will have a different behaviour between Node 1 and Node 2 as shown below:

o Node 1 sends useType="endPoint"

o a v2 get_bindingDetail returns "URLType=phone" on Node 1 but URLType="other" on Node 2. Node 1 sends useType="phone"

o a v3 get_bindingDetail returns "useType=endPoint" on Node 1 but useType="phone" on Node 2. As Node 2 cannot know that the binding was saved in v2, it cannot return the correct value on both API versions.

Minutes:

Andrew described the above scenarios. With the current spec., there is a loss of useType information across replicated nodes. The proposed solution does not make things lossless across both V2 and V3 because doing so would require V3 implementations to have knowledge of V2. Instead, it allows V3 to be implemented stand alone. The urlType in V2 really only let you pick among 6 values which are duplicated in the first part of the URL, and probably by the technical fingerprint tModels in the binding as well. So all V2 requests will still convert to “endpoint”, and the urlType will always convert to “other”. While the proposal is a somewhat lossy, it encourages people to put the right data in the accessPoint URL. Andrew felt this option also has the least chance of impacting an existing V2 client.

We reviewed several alternatives, some of which were closer to lossless. Comments from the TC indicated no one makes real use of the V2 urlType, and thus all agreed that the recommended option seems the simplest and best.

Motion to approve this CR for the v3.0.2 bucket: Approved.

5.4.7 CR059 – operationalInfo Problem in changeRecordPublisherAssertion

CR #	Document Identifier	Title / Action	Authors
CR-059	http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5421/uddi-spec-tc-cr059-crPubAssertOpInfo.doc	operationalInfo Problem in changeRecordPublisherAssertion	Andrew Hately

The replication schema and specification for changeRecordPublisherAssertion includes an operationalInfo element that is necessary for responding to subscription requests involving find_relatedBusinesses and get_assertionStatusReport filters.

Since there is no real operationalInfo element associated with a publisherAssertion or relationship, the interpretation of operationalInfo in changeRecordPublisherAssertion requires some clarification.

Minutes:

There’s no way to actually reuse operationalInfo for this purpose without changing it entirely. This CR removes operationalInfo and inserts a “modified” element to track when the data was last modified, since that’s the only piece of information really used. See the CR for details of the changes.

Motion to approve this CR for the v3.0.2 bucket: Approved.

5.4.8 CR060 – Remove Child Deletion from Policy Section

CR #	Document Identifier	Title / Action	Authors
CR-060	http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5404/uddi-spec-tc-cr060-removeChildDeletionFromPolicy.doc	Remove child deletion from policy section	Andrew Hately

The policy section currently states “The policy MUST state how the deletions of elements affect sub-elements” with respect to data integrity. This is not a matter of policy and is normative behavior.

Minutes:

This is a simple editorial change. This policy is not needed since it is normative behavior. Section 4.1.2.9.4.10 Registry Data Integrity is affected (2nd sentence to be removed).

Motion to approve this CR for the v3.0.2 bucket: Approved.

5.4.9 CR061 – Clarification of Combined categoryBags

CR #	Document Identifier	Title / Action	Authors
CR-061	http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5405/uddi-spec-tc-cr061-keyedReferenceGroupClarification.doc	Clarification of combined categoryBags	Andrew Hately

The V3 specification explanation for the behavior of the combineCategoryBags find qualifier does not specifically state how this qualifier treats keyedReferenceGroups versus simple keyedReferences. The correct behavior is that for find_business and find_service, the keyedReferences in categoryBags on the businesses and services and their contained entities respectively, are combined together prior to matching. Similarly, the keyedReferenceGroups are combined with each other before matching. The keyedReferences in categoryBags and keyedReferences in keyedReferenceGroups in categoryBags are not combined for purposes of the comparison. Left unstated, it might be possible to misinterpret and incorrectly flatten all of the keyedReferences inside keyedReferenceGroups together with each other.

Minutes:

This is essentially a clarification of behavior for combining keyedReferences with each other and keyedReferenceGroups with each other.

Motion to approve this CR for the v3.0.2 bucket: Approved.

5.5 V3 Issue: discoveryURL & overviewURL

Andrew submitted the following item for discussion:

During the course of implementing a V3 registry, we have found that the discoveryURL and overviewURL could cause interoperability issues due to the current state of schema assessment performed by various implementations on the XML Schema datatype anyURI.

From the XML Schema specification, it says it is lexically valid after applying the algorithm from XLink which could mean that certain characters outside of US-ASCII would be valid as long as they can be encoded later per XLink section 5.4.

Lexical representation

The ·lexical space· of anyURI is finite-length character sequences which, when the algorithm defined in Section 5.4 of [XML Linking Language] is applied to them, result in strings which are legal URIs according to [RFC 2396], as amended by [RFC 2732].

from XLink:

Some characters are disallowed in URI references, even if they are allowed in XML; the disallowed characters include all non-ASCII characters, plus the excluded characters listed in Section 2.4 of [IETF RFC 2396], except for the number sign (#) and percent sign (%) and the square bracket characters re-allowed in [IETF RFC 2732]. Disallowed characters must be escaped as follows:

1. Each disallowed character is converted to UTF-8 [IETF RFC 2279] as one or more bytes.

2. Any bytes corresponding to a disallowed character are escaped with the URI escaping mechanism (that is, converted to %HH, where HH is the hexadecimal notation of the byte value).

3. The original character is replaced by the resulting character sequence.

The result of the indirection in this definition is that some implementations of anyURI accept only characters defined in RFC2732, whereas others accept the Unicode characters that would result in valid RFC2372 URIs if processed by the algorithm in XLink.

The XML Schema group has acknowledged that for I18N reasons, the schema allows Unicode characters in anyURI and that for now clients should transform them to access/invoke the resource. I would like to know if the UDDI TC desires this flexibility as well. If the UDDI TC desires that the client be able to specify Unicode without escaping the non-ASCII characters, it may be beneficial for short term interoperability of UDDI implementations to change to the string datatype as is already the case with access points. Another option would be to place a post schema assessment restriction requiring that the publisher escapes the URIs per RFC2372 prior to publication.

Minutes:

Existing implementations vary in how they address this issue – interoperability problems should be expected. It generally remains the client’s responsibility to convert a URI into a URL that can be referenced via an internet call. This raises questions:

· do we want UDDI to have directly invokable URIs?

· should we expect clients to transform these URIs before using them? Note that clients such as Microsoft IE typically do such transformations automatically.

There are a number of ways to tackle this problem:

· change the type to a string (that gets over the interoperability issue).

· mandate that they be pre-transformed.

· leave this matter alone and expect that this issue will have been resolved in the next 2 yrs

Treating all of these URLs as strings would make everything consistent, though consideration should be made to convert the accessPoint into an anyURI instead of a string.

Daniel suggested creating a new UDDI specific URI type which is actually invokable, inheriting from anyURI. We’d describe the type in the spec indicating it is invokable. This would of course require us to version the spec when W3C & IETF finishes its work on IRIs.

At issue is whether we make UDDI independent of other specs, or whether we accept impact of changes in other specifications on UDDI implementations at any given time.

Luc proposed that Claus take this issue to the WS-I group. They have XML Schema as part of their profile and have constraints on schema. This may be the best forum since this is essentially a schema issue. We could then just say that WS-I Basic Profile compliant implementations would be interoperable.

NEW AR: AR-0027 - TC decided to take this item under advisement and ask Claus to discuss the issue with WS-I. We will review again based on feedback from this AR.

5.6 Spec/Standard Interop Demo at XML 2003

Discussion from sub-team on what we will pursue, the schedule and potential events.

Minutes:

Daniel gave an overview to the Steering Committee on activities to date. Work is continuing.

5.7 Discussion of “Representing Web Services Management Information in UDDI” TN Proposal

Adam Blum, Systinet and Fred Carter, Amberpoint proposed a Technical Note [1, 2]. Adam and Fred presented and discussed the proposal with the TC.

Minutes

We discussed of the proper way to proceed with this proposal.

Adam is keen to specify a consistent way of attaching the information to the UDDI objects (such as binding templates). Their original proposal specified four ways in which it could be done – this richness of opportunity is an invitation to diversity of implementation, which doesn’t make for good interoperability.

The preference is to model all this in the existing V3, but it is good to keep an open mind – perhaps a change to UDDI might enhance the usefulness.

There was considerable discussion of how this works, and more importantly, why it is done this way. A variety of use cases emerged, including two important divisions of information. There are the end-user use cases, which are mostly slower-changing / aggregated data elements, and the management software use cases, which relate to bindings to the actual data access mechanisms. In some cases, these will be multiple bindings to the same service (using supplementary bindings that give the management data access paths), but there are times that these must not be exposed, so the bindings may be to different services that can be linked.

There is an interesting issue – whether the installer of the data supply services and the management software are the same entity or different. The case where they are different is more difficult, and so we will attempt to solve it first.

WSDM is planning to specify a limited number of metrics, and the plan is that these will form the basic set that would be supported by this proposal, but that this is regarded as just a starting point – each vendor of management software is likely to extend this set with their own “enhanced” metrics.

Most importantly, we concluded that should have an official liaison to the WSDM TC, because this proposal interacts closely between the two TCs. Probably the most appropriate division of labour is to have the WSDM TC define the various metrics that will be used, and have the UDDI TC determine the appropriate representation of this kind of information in the registry. Fred volunteered to operate as the WSDM liaison.

5.8 Steering Committee Discussion

The Steering Committee was represented by Mike De Nicola (Fujitsu), Eric Hammer (Intel) and George Zagelow (IBM, Chair).

George gave a presentation about the UDDI member section at OASIS; the history of the steering committee, starting from UDDI.org; its goal to increase the size of the member section – made complex by rules concerning member sections; and current work:

· Updating Solutions page

· Customer references

· UDDI Promotion list

You can find a copy of the presentation at http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5565/UDDI%20SC%20Status%2020040211.ppt.

George also asked for input on what else should the SC be doing to assist the TC and the UDDI community?

Tom made a request to the steering committee for funding for the facilities for the UDDI F2F in NZ. Question arises as to whether there might be a problem with approval of this expenditure – OASIS has approval of any expenditure.

Tom will put the request into writing, and the Steering Committee will consider it, and forward to the OASIS management.

When asked by George when we believe that we may submit v3 (and scc14n) to standardization, Tom suggested that we’re probably looking at releasing 3.0.2 as an errata list in summer, and then submitting the specs for standardization towards the end of 2004.

Note: The SC and OASIS have subsequently approved the funding request.

6 UDDI v.Next Discussion of Proposals

Our current plan for reaching completion of our v.Next effort can be found in the uddi-vnext-requirements-list.htm at http://www.oasis-open.org/apps/org/workgroup/uddi-spec/documents.php.

The latest copy of this document is: http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5648/uddi-vnext-requirements-list.htm

6.1.1 WS-Security Compatibility REQ 04

Minutes:

We discussed Andrew’s document in more detail than the previous telecon, and came to the same conclusion: that no adjustment to the specification is required, but that a couple of TNs should address the TC’s recommendations in this area.

6.1.2 Taxonomy Management - REQ 11-14

NOTE: The requirements below remain to a large extent though they will be handled by RQ 028 focusing exclusively on Taxonomy Management. Semantic search capabilities that had been discussed loosely as part of this requirement where split from this requirement during the 20040110-12 FTF and will be covered separately by RQ 029.

Minutes:

Discussion

We need to define what semantic support means in the context of UDDI. Is it to establish relationships between entities and allow one to perform searches that allow one to broaden the search filters allowing for semantically equivalent result sets (i.e., up or down the parental & equivalence relationship hierarchy)? Whether this implies internal vs. external server support is largely an open issue.

We debated the value of allowing user defined OWL schemas vs. choosing an OWL-based value set schema (as proposed by Luc at [7]) which supports UDDI-like parent, child & equivalency relationship capabilities as the basic set of requirements for supporting taxonomies with UDDI. The latter takes a more restricted view of much of the discussion so far, and makes clients adapt their data to the UDDI model chosen, but may represent a more containable approach that lets the TC support inferencing later or a vendor to innovate.

Luc presented an “OWL-lite” schema which could be used to address the storing of an ontology in UDDI (valueset.owl) file - see [7]. We debated the options of either specifying the taxonomy with the parent/child relationships implied by having nested structures within structures (this is Systinet’s approach), vs. naming each element and expressing the relationships independent of structure as in Luc’s proposal. Each approach has its benefits; the former is probably easier to read and edit as a whole, but the latter may be easier to incrementally edit and maintain. This remains an open issue.

We still need to look at how one would specify equivalence within Luc’s proposal between nodes of two or more value sets. We should explore how OWL enables this in the context of schema.

There was also a proposal which John Colgrave had submitted (see [8]), and which we discussed in his absence: John wants to do as little UDDI specific work as possible to limit the amount of UDDI specific requirements designers need to build in when they define taxonomies. He has concerns that we may be premature in selecting OWL, although it currently appears as the best option.

What is the advantage for OWL over XML Schema? Luc (though not convinced) feels vendors may eventually support OWL parsers over time – this may reduce the resistance to adoption particularly now that OWL is a W3C Recommendation. We discussed that rather than using OWL that we could simply define an UDDI specific vocabulary using XML schema given that we did not necessarily need the full expressivity of OWL. Whether or not we’d really be gaining much by using an OWL schema approach proposed by Luc vs. defining an XML schema is still an open issue. We concluded that much of this was still speculative and needs further consideration.

John doesn’t see the need for a UDDI value set schema; this is also Max’s point of view. John feels it’s unreasonable to expect users to rewrite their ontologies to fit with UDDI, and that it loses many of OWL’s capabilities if we do this. This view is largely based on the premise that semantic search capabilities should be exploited by inferencing engines external to a UDDI server.

Daniel feels that we should not over-emphasize the need to have ontologies be internal to the registry. He suggests we define an API set that is optional to save/manage/navigate ontologies in UDDI. The TC wants to ensure that either internal or external inferencing is supported, though still feels that having the ability to store/manage/navigate a taxonomy inside UDDI remains a requirement, independent of the syntactic mechanism with which we do it or semantic search requirements which we may consider.

We concluded that while there was merit to support either or both internal vs. external inferencing, that this should not deter us from addressing a key requirement of storing/managing/navigating value sets in UDDI.

Luc proposed that we leave the schema decision (OWL-Lite vs. an XML Schema) as an open issue for now, and proposed that we define API approaches that satisfy our needs. Modeling how to annotate entities or value sets which support reasoning requiring perhaps both find qualifiers and value set annotations (upward, downward, and equivalencies between nodes of various value sets) should be treated as a separate issue.

We concluded that the discussions to date can be boiled down to two distinct requirements:

1) Create a new API set to save/delete/navigate/manage taxonomies including defining a (OWL or XML) schema for representing these.

2) Enhancing the existing search APIs to support semantic operations using for example the relationship information contained in a taxonomy (with the implication that we would support internal server-based inferencing).

Decision

To simplify and focus the Taxonomy work from here on, the TC has decided that we will work toward a solution under the following set of guidelines.

We will satisfy the requirements of:

· Enable internalization of taxonomies in UDDI

· Maintain ability to reference and operate with external taxonomies

· Enable ability to support internal or external (to UDDI) inferencing

· Support I18N via the richness of client interfaces. Value set values are not generally internationalized.

We have decided to standardize the following minimal set of features:

· Define a standard format for representing a value set.

· Define an XML-based schema for representing value sets.

· Define standard APIs for save/delete/manage value sets.

· Define standard APIs which allow navigation of these value sets.

· Restrict value set relationship support to a single root node relationship tree (root node can always be bootstrapped). This supports the majority of known UDDI customer use cases.

· That value set based description will support specification of relationship information identifying parent and child relationships.

The following inquiry scenarios should drive the features we intend to support in the area of semantic reasoning:

· “find all entities who are classified as within Texas…” – requires traversing down relationship hierarchy

· “find all things which are like books” – requires use of equivalence across a value set

· “find all things that are publications by looking for things that are books” – requires traversing up the hierarchy

So, support the semantic reasoning scenarios in which we are interested, we ALSO need to standardize these features:

· Define updates to the inquiry APIs which enable searching using basic reasoning (up, down and across (equivalence) a tree).

· Extend our value set schema (either XML or OWL based) to allow establishing equivalence between nodes in the same ontologies.

Nice to have semantic items which are not required but are valuable:

· Extend our value set schema (either XML or OWL based) to allow establishing relationships between nodes in different ontologies.

· Extend value set schema to allow establishing equivalencies between different value sets.

· Standardize mapping from the UDDI value set schema to an OWL-based schema.

· Support an OWL (or some RDF like) schema to save ontologies in UDDI. This would enable leveraging of future OWL based tools to make reasoning solutions cheaper to implement (it is debatable if this will prove to be true).

Additional considerations for developing proposals:

· Must consider that a saved taxonomy may only be published on one node. Same problems as for keyGenerators and thus the full set of replication issues identified with keyGenerators need to be considere.

· Must be able to transfer taxonomy data through replication to other nodes.

· Must decide on how to handle changes publishers make in taxonomy data to references in the registry that are no longer valid (dangling references, fix-up, etc.)

The TC has decided to deprecate the REQ011-014 documents and replace these with two separate set of requirement.

NOTE: The requirements identified by REQ 011-014 are still valid to a large extent though they will be handled by RQ 028 focusing exclusively on Taxonomy Management. The principles identified above take precedence. Semantic search capabilities that had been discussed loosely as part of requirements 11-14 where split from the discussion of Taxonomy Management during the 20040110-12 FTF and will be covered separately by RQ 029.

The new requirements are:

· REQ-028 - Taxonomy Management Requirements (We will focus ONLY on the MUST haves for this first, then layer in the nice to have’s afterward)

o Requirement Document (DUE 2/25) Owners: Tony, Luc and Mirek

§ Reviewers: Daniel, Max, John

Action Item: AR-0028

o Proposal Document (DUE for 3/2 telecon) Owner: Daniel

§ Reviewers: Tony, Luc, Mirek, Max, John

Action Item: AR-0029

· REQ-029 - Semantic Requirements. (We will focus ONLY on the MUST haves for this first, then layer in the nice to have’s afterward)

o Requirement Document (DUE 2/25) Owners: Rob

§ Reviewers: Daniel, Max, Tony, Luc, John

Action Item: AR-0030

o Proposal Document Owner: TBD (possibly John? - decide at next telecon)

§ Reviewers: Daniel, Max, Tony, Luc, John, Mirek

Action Item: TBD

6.1.3 Access Control REQ 16

Minutes:

Noted in working draft http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5550/uddi-spec-tc-prop016-acls.doc

Points raised during the discussion of Access Control:

· Restrict ACLs to entire entities. Decide to avoid providing ACLs on elements at this time – ugly to specify, ugly to code, serious overhead…

· Format of ACLs? Intent to support a variety of AC standards, be flexible without being over-specific. This is because the AC language is likely to be tightly bound to the authentication mechanism, which should be outside the scope of UDDI. Unfortunately, this makes it much more difficult to write a coherent specification, because we don’t know what the implementer will be using for the ACLs.

· Andrew’s favoured approach is to break the containment model, so that services and bindings can be saved independently. This allows the defining of ACLs on top level entities with greater simplicity, and removes need to consider inheritance of ACLs.

o This idea raised considerable comment, and it has been suggested that doing this is out of scope for a v.Next that is V3.1 – this is more a V4 idea

o It may be appropriate to consider solutions that do not break the containment model

· When saving a service, must it have a business key?

o This caused considerable discussion. It’s a consequence of breaking the containment model. When we save a service that is not contained, need it be attached to a business, or not? Both possibilities were discussed, but this issue was not resolved.

· Who controls the list of services under a business? Is a service saved “in” a business, or does a business get saved with a list of service keys? Or do we need to consider another model for connecting a service to a business (perhaps something like the proposal discussed later under Contacts: REQ27, where an assertion is used?)?

· We need to work out how to specifying access controls for:

· Who can create a business? Service? Binding? TModel? (and should this be controlled by ACLs? Or by policy?)

· How do we provide ACLs? It was agreed that they must be part of the save call to make them atomic with the data save – it would not be acceptable for the entity to be saved without ACLs and then to have the ACLs applied in a second call, leaving a window of opportunity between the calls.

· Can we change an ACL outside of a save? We probably need an API for saving ACLs without saving data (if nothing else, so we can save default ACLs).

· Default ACLs – most basic is: everyone can read, only publisher can change (existing setup)

· Abilities to specify default ACLs for:

o Registry – what is the default ACL for anything saved in this registry that does not have an ACL defined

o User – what is the default ACL for anything saved by this user that does not have an explicit ACL defined

o Keyspace (everything within a keygenerator) – what is the default ACL for anything saved with a key starting with this keygenerator that does not have an explicit ACL defined – this is a powerful option, because it allows control over ACLs through the selection of keys, and does not require the explicit specification of ACLs on the save.

Action Items:

· AR-0031: Andrew to complete work on RQ-016 proposing the approach he advocates.

o TC to consider this approach, and decide whether breaking the containment model is acceptable in context.

· Do we have a volunteer to write a proposal that does not entail the breaking of the containment model?

6.1.4 Improving Trustworthiness REQ 18

Minutes:

Noted in http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5549/uddi-spec-tc-req018-trustworthyQuery-20031028.doc

Action Items:

· AR-0032: Andrew and Claus to draft a proposal using WS-Policy to address machine assessment of registry policy

· Discover if we have a member of the TC who is on the DSS TC; should establish a liaison with them

· AR-0033: Tony to draft a proposal addressing how a registry can provide additional validation beyond the current (validate at publish time) – including “validate at query time” and “validate on a regular basis”. This proposal will also look at REQ19 (stale data).

· AR-0034: A technote on the subject of securing the channel would be sensible. Rob Kochman to produce the TN.

6.1.5 Extended Find Qualifiers for Bags REQ 20

Minutes:

We went through several versions of the proposal. The latest version of the proposal is posted at http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5396/uddi-spec-tc-prop020-ExtendedFindQualifiersForBags-20040209.doc.

Action Item:

· AR-0035: Daniel to clean up the final version and repost. DUE 2/25.

6.1.6 Keyed Reference Group Behavior Override - REQ 23

Minutes:

We went through several versions of the proposal. The version we decided to adopt expands the requirement to allow the persisting of ranges within categoryBags. The solution discussed will allow discovery using one or more ranges and will support inclusive/exclusive behavior in such comparisons. The latest version of the proposal is posted at http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5444/uddi-spec-tc-prop023-keyedReferenceGroup-20040211.doc.

Action Item:

· AR-0036: Daniel to update the requirements document to match change in focus as above. DUE 2/25.

· AR-0037: Daniel to redesign the proposal and repost by next FTF (target 3/15).

6.1.7 Contacts Requirement – REQ 27

Minutes:

The requirements document was updated. The latest version of the requirements document is posted at: http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5551/uddi-spec-tc-req027-contacts-20040101.doc.

The key ideas are:

· separate the contact structure from the business entity and give it a key

· a single contact may be referenced from multiple locations – reduced duplication and eased maintenance

· a contact may include reference to an external identity store

· add contact references to services, bindings, and tModels – make it possible to say “contact this person when this binding is off-line”

· solve some access control issues by having a different publisher control a contact from the publisher controlling the business

· CRITICAL QUESTION: who controls the link between the business and the contact?

o Definitely not the contact publisher (“I am the CEO of this business – honest!”)

o Possibly the business publisher (“All these people are connected with this business – trust me!”)

o Possibly re-use the publisher assertion concept to link a contact to a business/service/binding/tModel only when both sides have asserted the link?

· Adjunct to this is the idea of a GetQualifier, which allows the user to specify that they want all contacts that are referenced by an entity returned with the entity (along the lines of the situation today, where contacts are returned in a business entity). It’s possible to extend this idea, and have GetQualifiers for other references (do we want service projections? Do we want the target of a HostRedirector? Perhaps even all tModels referenced?)

7 Adjournment

We adjourned at 16:30 Thursday 12 February 2004.