wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] modifyRegistrationRequired fault
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Mon, 13 Dec 2004 09:10:25 -0500
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 ...
Rich
Andre Kramer <andre.kramer@eu.citrix.com>
12/10/2004 04:55 AM
|
To
| wsrp@lists.oasis-open.org
|
cc
|
|
Subject
| [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)?
E.g.
<complexType
name="ModifyRegistrationRequiredFault">
<complexContent>
<extension
base="types:InvalidRegistrationFault">
<sequence/>
</extension>
</complexContent>
</complexType>
<element
name="ModifyRegistrationRequired"
type="types:ModifyRegistrationRequiredFault"/>
Regards,
Andre
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]