<p>OASIS UDDI Spec Technical Committee</p><p>Minutes of UDDI Spec TC Telecon</p><p>Date: 20060622</p><p>Chairs: Luc Clément, Systinet, [email protected] Tony Rogers, CA, [email protected]</p><p>Logistics </p><p>TC Telecon Call hosted by Luc Clément, Systinet</p><p>Dial in Tel Number: +1 973-935-8394 Domestic US & Canada: 866-240-0534 Participant Passcode: 965471</p><p>Time Conference call times are as follows by region: UTC: Tue-21:00 Seattle: Tue-13:00 New York: Tue-16:00 London: Tue-21:00 Frankfurt: Tue-22:00 Melbourne: Wed-06:00</p><p>Agenda</p><p>1 Attendance...... 1 2 Additions to Agenda...... 1 3 Approval of Previous Minutes...... 2 4 Administration...... 2 4.1 Next Call...... 2 5 Old Business...... 2 5.1 Technical Notes...... 2 5.1.1 “Understanding Key Partitions” Technical Note...... 2 5.1.2 “Representing Property Information” Technical Note...... 2 5.1.3 “Using WS-Addressing and UDDI” Technical Note...... 3 6 New Business...... 3 6.1 Errata: Handling large results missing in some publication API calls...... 3 7 Additions to Agenda...... 3 8 Adjournment...... 3 9 Tabled...... 3 9.1 Replication inconsistency...... 3 9.2 UBR and Effects on the Spec...... 3 9.3 Transport and Protocol tModels...... 3 9.4 Taxonomy Management...... 3</p><p>1/6 OASIS UDDI Spec Technical Committee</p><p>1 Attendance</p><p>Company or Member Name Organization 20060822 Clement, Luc Systinet y Colgrave, John IBM Dovey, Matthew Individual Downey, Paul BTplc Garbis, Jason Systinet y Hately, Andrew IBM y Kochman, Rob Microsoft y Macias, Paul A. LMI Mikulinsky, Oleg WebLayers Prout, Dave BTplc Computer Rogers, Tony Associates y Sharma, Shamik SOA Software von Riegen, Claus SAP AG y</p><p>2 Additions to Agenda</p><p>Minutes: None</p><p>3 Approval of Previous Minutes </p><p>Motion: Motion to approve the minutes of the last telecom: http://www.oasis- open.org/apps/org/workgroup/uddi-spec/download.php/19871/Minutes-v1-20060613.doc </p><p>Minutes: Approved without dissent.</p><p>4 Administration</p><p>4.1 Next Call</p><p>Next call scheduled: 12 Sep 06</p><p>Volunteer to host the next call needed.</p><p>Minutes: Claus will host.</p><p>2/6 OASIS UDDI Spec Technical Committee</p><p>5 Old Business</p><p>5.1 Technical Notes</p><p>5.1.1 “Understanding Key Partitions” Technical Note</p><p>Luc has submitted the first edited draft. Update posted by Luc at http://www.oasis- open.org/apps/org/workgroup/uddi-spec/download.php/17947/uddi-spec-tc-tn- understandingkeypartitions-20060502.doc</p><p>Status during last telecon: Andrew is working on the diagrams, and the diagramming software is fighting back – the text updates are complete. </p><p>Open Items:  Action: Andrew to do second edit pass and submit to TC  Next step will be a TC review and vote to approve.</p><p>Minutes: Andrew has submitted a final version of the document; </p><p>ACTION: Luc to do final processing and post the final version.</p><p>5.1.2 “Representing Property Information” Technical Note</p><p>Status: Update posted by Jason a t http://www.oasis- open.org/apps/org/workgroup/uddi-spec/download.php/18292/uddi-spec-tc-proposal- representing-property-information-2006-05-22.doc</p><p>Editors: Andrew, Tony and Claus</p><p>Open Items:  Action: Editors to complete edit pass</p><p>Minutes ACTION: Andrew to take the next pass on this document. Tony to take the one after.</p><p>5.1.3 “Using WS-Addressing and UDDI” Technical Note Update posted by Jason at: http://www.oasis-open.org/apps/org/workgroup/uddi- spec/download.php/18916/uddi-spec-tc-tn-usingwsa-2006-06-23-JAG-edits.doc </p><p>Editors: Jason and Andrew. Edit pass after Tony has submitted the next revision incorporating changes spurred by Jason’s comments</p><p>Open Items:  Action: o Done: Jason to complete edit pass o Andrew to complete edit pass o Tony to fold in comments</p><p>Minutes ACTION: Luc to take an edit pass over this document.</p><p>3/6 OASIS UDDI Spec Technical Committee</p><p>6 New Business</p><p>6.1 Errata: Handling large results missing in some publication API calls</p><p>Background From: von Riegen, Claus [mailto:[email protected]] Sent: Tue 11-Jul-06 17:11 To: [email protected] Subject: [uddi-spec] Handling large results missing in some publication API calls</p><p>All, </p><p>There are some Publication API calls in UDDI 3.0.2 that don't provide the capability to manage large result sets, particularly </p><p>- get_assertionStatusReport - get_publisherAssertions - get_registeredInfo </p><p>This was not a problem for the UDDI Business Registry nodes because all these API calls relate to the management of entities published by an individual publisher and there were certain publication limits. However, it is up to a UDDI node's policy (as described in section 9.5.6 Node Publication Limits) whether there are actually such limits. </p><p>One example when such limits should not apply is the need for the publication of a large set of tModels, let's say something between 1k and 10k, and the publication needs to be done by a technical user in order to guarantee consistency and up-to-dateness. Calling the get_registeredInfo API with the technical user would represent a problem since the result set is too large and there would be no capability to retrieve the result set in chunks. </p><p>We believe that this is a bug and propose to clean up the above listed API calls by adding the maxRows and listHead attributes to the API calls and the listDescription element to the return structures with the meaning as described in section 5.1.5 Use of listDescription. </p><p>Minutes TC suggests that we do this as an erratum with a change in namespace. Andrew recommended that we only change the namespace of the affected elements, to allow backward compatibility.</p><p>ACTION: Claus raise for a Change Request for this erratum. ACTION: Luc to resuscitate the CR list for management of Change Requests for V3.</p><p>7 Additions to Agenda</p><p>Minutes None.</p><p>8 Adjournment</p><p>Minutes Adjourned until 12 September.</p><p>4/6 OASIS UDDI Spec Technical Committee</p><p>9 Tabled </p><p>9.1 Replication inconsistency Re: http://lists.oasis-open.org/archives/uddi-spec/200512/msg00009.html</p><p>As Claus pointed out, there is a minor inconsistency between the spec and the schema in the replication API. The spec states that originatingUSN is mandatory, but the schema specifies it as minOccurs=0. The suggested change is to change the schema to minOccurs=1.</p><p>Discussion:  General agreement that a change request will be raised for this. </p><p>Action:  Luc will generate the request, then run it by Claus, at which point the TC will decide how to handle errata</p><p>Minutes</p><p>9.2 UBR and Effects on the Spec Open discussion:</p><p> http://lists.oasis-open.org/archives/uddi-spec/200512/msg00020.html  http://lists.oasis-open.org/archives/uddi-spec/200512/msg00021.html  http://lists.oasis-open.org/archives/uddi-spec/200512/msg00022.html</p><p>Discussion: The TC agreed to run this and the previous item through as a single errata document. It was agreed that this did not justify revising the document versions.</p><p>Action:  Luc: pass through the spec and identify updates to be made  Luc: to proceed with revising the TC’s charter  Luc: to generate the Change Requests.</p><p>Minutes</p><p>9.3 Transport and Protocol tModels</p><p>Further to http://www.oasis-open.org/apps/org/workgroup/uddi- spec/email/archives/200506/msg00003.html where: We (Systinet in the context of a project) have reason to want to map a service as communicating over IBM MQ and using XML (i.e. XML/MQ vs SOAP/HTTP vs SOAP/TCP). We’re about to define tModels for this but I wanted to know whether there would be interest in coming up with a list of transports and protocols that supplements those we identified in the v3 spec and the WSDL-UDDI TN. I’d be happy to collect these and write a TN. Doing so would greatly cut down on duplicative definitions. Please let me know your thoughts and transports/protocols you’d like considered. ... find below examples of "things" that are being identified. </p><p>Name Type Values xxx-org:yyy:jms xxx-org:yyy:file xxx-org:yyy:requestresponse xxx-org:yyy:requestonly </p><p>5/6 OASIS UDDI Spec Technical Committee</p><p> xxx-org:yyy:anysoap xxx-org:yyy:anyxml xxx-org:yyy:messagingservice </p><p>Would like to discuss whether there is interest in collecting and identifying a common set of representations/nomenclature/definitions.</p><p>Status: This TN has stalled while Jason worked on the previous one, but there is added demand for it.</p><p>Luc and Jason were to provide draft by 21 Feb 06 meeting</p><p>9.4 Taxonomy Management The lack of a standard format / API for taxonomy transfer between UDDI implementations. This was high on the list for the v.Next discussions – see: http://www.oasis- open.org/apps/org/workgroup/uddi-spec/download.php/8693/uddi-spec-tc-prop028-owl- 20040813.doc </p><p>John pointed out that this document is not appropriate as a TN – a TN is about how to use the UDDI APIs; this is more about how a UDDI node operates, making it more of a specification document. The TC agreed, and decided to take this down the specification route. </p><p>John is having trouble finding the time to work on this. He asks if someone else could tackle the job of turning his work into a TN. No one on the call today volunteered. This is an important subject, and it would be helpful if someone could spare the cycles to work on it. Perhaps a member of the TC who was not on the call today will volunteer?</p><p>Minutes The suggestion is that the TC consider making this a standard-level specification document, rather than releasing it as a Technical Note. There are implications to making this normative. The members of the TC are asked to investigate whether their organization is willing to support a normative specification made from John’s document. </p><p>Andrew commented that the change requiring spec change was the support for relative URIs and absolute URIs being equivalent in a keyed reference in both publication and search, and asked if we could consider creating an import / export format that required no changes in the base spec – this could be done in a TN. Andrew pointed out that this would require locating OWL files individually, and require more work when attempting to use the import/export format. This might, however, be more widely acceptable. </p><p>6/6</p>