Document Details (Active Version)
Document Name: RUPI Rendering Document - ODF version Document ID: doc15578 Description: The initial version of the RUPI rendering document as discussed at OGF25 Version Comment: CHANGES FROM PREVIOUS VERSION: changed reference of SOAP 1.2 from [SUAP 1.2] to [SOAP 1.2] Page 5 - fixed error: '/s12:Envelope/s12:Body/rupi:PublishResponse' changed to '/s12:Envelope/s12:Body/rupi:PublishConstraintsResponse' Various spelling corrections have been added. Some clarifications have also been given where proof readers were unclear about the contents of a particular paragraph. When describing constraints mechanism, 'MUST' has been changed to 'must' as it capitalisation indicates terminoligy that is not strictly appropriate here. Changed function of Publish operation. The original operation allowed records to potentially be overwritten if the consumer alreay contaned a record with the same recordId. As the NGS pointed out, this is a logistical nightmare as alterations may very well require an audit log and the ability to revert changes. The former is implementation specific but the latter may well need an operation from the producer to enforce this policy. Such an operation is not present in RUPI, nor should it be. Modifying records should be left to other specifications - this is just a pubishing interface. As such, the new Publishing interface may report that the record is a duplicate and so will not be stored again, but will not replace a record currently being stored with one being uploaded. The extension mechanism has been modified. Originally, xsd:any elements were present at certain points in messages to allow extensions to be added. Now, an abstract element rupi:ExtensionElement takes it's place. Extension elements can extend from this element. This is apparently better practice. I can certainly see how it could be so. Added nominative WSDL. Colour coding comes from eclipse so I'm afraid it won't change appropriately if you alter the text Added warning about possible denial of service attack via records uploaded with recordIds identical to ones a legitimate user will use to prevent them from uploading records. Added recommendations about storing extra credentials with records. Specifically, the person/authority that uploaded the records and the time they were uploaded Added requirement that rupi:PublishRecordResult elements must appear in the same order as the records that were uploaded. This makes it easier for producers to check response messages, make sure all has gone smoothly and identify problems when they arrise. This is also helpful when a faulty record does not contain a recordId or two records are uploaded that have the same recordId. Extra information can be gained from the rupi:PublishRecordResult's position in the response message. Made recordId optonal in the rupi:PublishRecordResult element. This is necessary to allow for situations where a malformed record that doesn't have an id is uploaded. Now that the ordering of rupi:PublishRecordResult elements is fixed, the necessity to have a recordId present under all situations is no longer present (although, of cause it provides a useful validation mechanism). DuplicateRecordFault removed. It is only used in the publish operation which already has the ability to note a duplicate by returning the 'Duplicate' token as it's rupi:PublishOutcome. Added a rupi:Description element to the publish response message. The element holds a string in which extra information about the publish operation can be stored. Multiple rupi:Description elements may be present. They may optionally contain a descriptionKey. rupi:PublishRecordResult elements may also contain descriptionKey attributes to tie them to discriptions given in the response message. A key is specified rather than an actual discription because many (1000s) of records may wish to provide the same discription. This mechanism allows the discription to be given once and referenced by each rupi:PublishRecordResult element that is interested in it, making the message size considerably smaller The language used to describe record constraints was technically broken. It has been modified to correct for it's previous failings Removed the ability to return faults on a per-record basis in the Publish response. This functionality has been replaced with the ability to return more types of outcome (namely, 'Ignored', 'Malformed' and 'NotAuthorized'). Reasons for why these events happened can be returned using the new description mechanism which is much more efficient than returning many faults that will probably be identical on a record by record basis Version Created By: Joshua Green - 05/28/2009 4:42 AM EDT	Status: Draft Current Version: 2 Size: 48.05 KB Lock:  Unlocked

	Versions		Associations		Review

	Active	Version	Version Comment	Review	Created By	Status
		Version 2	CHANGES FROM PREVIOUS VERSION: changed reference of SOAP 1.2 from [SUAP 1.2] to [SOAP 1.2] Page 5 - fixed error: '/s12:Envelope/s12:Body/rupi:PublishResponse' changed to '/s12:Envelope/s12:Body/rupi:PublishConstraintsResponse' Various spelling corrections have been added. Some clarifications have also been given where proof readers were unclear about the contents of a particular paragraph. When describing constraints mechanism, 'MUST' has been changed to 'must' as it capitalisation indicates terminoligy that is not strictly appropriate here. Changed function of Publish operation. The original operation allowed records to potentially be overwritten if the consumer alreay contaned a record with the same recordId. As the NGS pointed out, this is a logistical nightmare as alterations may very well require an audit log and the ability to revert changes. The former is implementation specific but the latter may well need an operation from the producer to enforce this policy. Such an operation is not present in RUPI, nor should it be. Modifying records should be left to other specifications - this is just a pubishing interface. As such, the new Publishing interface may report that the record is a duplicate and so will not be stored again, but will not replace a record currently being stored with one being uploaded. The extension mechanism has been modified. Originally, xsd:any elements were present at certain points in messages to allow extensions to be added. Now, an abstract element rupi:ExtensionElement takes it's place. Extension elements can extend from this element. This is apparently better practice. I can certainly see how it could be so. Added nominative WSDL. Colour coding comes from eclipse so I'm afraid it won't change appropriately if you alter the text Added warning about possible denial of service attack via records uploaded with recordIds identical to ones a legitimate user will use to prevent them from uploading records. Added recommendations about storing extra credentials with records. Specifically, the person/authority that uploaded the records and the time they were uploaded Added requirement that rupi:PublishRecordResult elements must appear in the same order as the records that were uploaded. This makes it easier for producers to check response messages, make sure all has gone smoothly and identify problems when they arrise. This is also helpful when a faulty record does not contain a recordId or two records are uploaded that have the same recordId. Extra information can be gained from the rupi:PublishRecordResult's position in the response message. Made recordId optonal in the rupi:PublishRecordResult element. This is necessary to allow for situations where a malformed record that doesn't have an id is uploaded. Now that the ordering of rupi:PublishRecordResult elements is fixed, the necessity to have a recordId present under all situations is no longer present (although, of cause it provides a useful validation mechanism). DuplicateRecordFault removed. It is only used in the publish operation which already has the ability to note a duplicate by returning the 'Duplicate' token as it's rupi:PublishOutcome. Added a rupi:Description element to the publish response message. The element holds a string in which extra information about the publish operation can be stored. Multiple rupi:Description elements may be present. They may optionally contain a descriptionKey. rupi:PublishRecordResult elements may also contain descriptionKey attributes to tie them to discriptions given in the response message. A key is specified rather than an actual discription because many (1000s) of records may wish to provide the same discription. This mechanism allows the discription to be given once and referenced by each rupi:PublishRecordResult element that is interested in it, making the message size considerably smaller The language used to describe record constraints was technically broken. It has been modified to correct for it's previous failings Removed the ability to return faults on a per-record basis in the Publish response. This functionality has been replaced with the ability to return more types of outcome (namely, 'Ignored', 'Malformed' and 'NotAuthorized'). Reasons for why these events happened can be returned using the new description mechanism which is much more efficient than returning many faults that will probably be identical on a record by record basis		Joshua Green - 05/28/2009	Draft
		Version 1	Initial draft - uploaded for comment (ODT Version)		Joshua Green - 03/17/2009	Draft

Return     Open Document     < Previous     Next >