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 16:45:56 -0500
Since this is just a schema definition
of what flows on the wire, I don't see an advantage to introducing an intermediate
definition as it will never appear on the wire and does not factor out
any structural definitions.
Rich
Andre Kramer <andre.kramer@eu.citrix.com>
12/13/2004 09:27 AM
|
To
| wsrp@lists.oasis-open.org
|
cc
|
|
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 (ctf InvalidHandle?). In this view both ModifyRegistration
and InvalidRegistrationFault could extend a base RegistationFault.
Regards,
Andre
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 ...
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]