OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrp] modifyRegistrationRequired fault

The case I was attempting to make is that the modify registration fault is an "extension" of a registration fault that can be recovered from. I understand that one can view InvalidRegistrationFault more as commandment to never again use the registration handle rather than a signal that a registration is, say, temporarily unavailable (cf InvalidHandle?). In this view both ModifyRegistration and InvalidRegistrationFault could extend a base RegistationFault.





From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 13 December 2004 14:10
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] modifyRegistrationRequired fault


I do not think the ModifyRegistrationRequired fault should extend InvalidRegistration fault as their semantics are quire different (repair this registration vs destroy this registration's artifacts). As to an expanded description ... sounds like a good idea, I kept the initial pass concise as this is in keeping with the other definitions in the table, but am open to expansion of this or other fault descriptions. We should be careful about what is prescribed behavior, though, as not all Consumers will be portals with administrators ...


Andre Kramer <andre.kramer@eu.citrix.com>

12/10/2004 04:55 AM






[wsrp] modifyRegistrationRequired fault




The draft spec does not seem to give much guidance on how to handle the new proposed fault? I would expect consumer processing for an end-user to abort on the fault (affected portlets are not rendered) and an admin to be notified to go and attempt a modifyRegistration operation interaction with the faulting producer (correct me if I'm wrong but Portal users may not even see the new modified registration until they log in again). This leads me to two questions:

Should example usage of the new fault be better described?

Should the fault type be declared to extend the 1.0 InvalidRegistrationFault (or a common base type be inserted)?


<complexType name="ModifyRegistrationRequiredFault">


      <extension base="types:InvalidRegistrationFault">





<element name="ModifyRegistrationRequired" type="types:ModifyRegistrationRequiredFault"/>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]