|
|
|
David Snelling: 02/01/2007 2:04 PM EST
|
| |
Comment: |
These changes were evident in the Last Call and no comments arose, so Closed Tracker.
|
| |
Action: |
Update
Closed set to 02/01/2007
Status changed from Pending to Closed
|
|
|
None: 11/03/2006 3:00 AM EST
|
| |
Comment: |
Section 4.2 appears to cater for multiple URIs in the EPR. I find it dificult to see why a SOAP message should contain more than one. I have not
changed this section. This is consistent with the usage of the Address field as an identifier, since only one wsa:To field isa allowed.
The Metadata section of the EPR already allows multiple instances of what ever is needed there, so no schema changes were needed.
The exception was in the fault messages, I enabled the schema with the ability to include multiple EPRs of both types.
Closure still to be agreed by the WG.
|
| |
Action: |
Update
Assigned To changed from David Snelling to Andrew Grimshaw
|
|
|
Andrew Grimshaw: 10/02/2006 12:08 PM EDT
|
| |
Comment: |
Change schema as described to allow multiple resolver EPR's
|
| |
Action: |
Update
Assigned To set to David Snelling
Status changed from Open to Pending
|
|
|
David Snelling: 09/15/2006 10:55 AM EDT
|
| |
Comment: |
This is currently not supported by the current document.
To enable multiple EPR (and EPIs if the other fualt type is added), we will need to change the schema to allow 1..unbounded elements.
We should make this change to the fault messages.
With respect to the return from the operations we should only allow one EPR, which can already contain multiple EPIs if necessary. We should keep the
base case as simple as possible.
|
| |
Action: |
Update
Priority changed from 0 to 1
|
|
|
|
