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: Wed, 15 Dec 2004 08:50:05 -0500
My view is that unless the specification
has clearly stated either a structural or semantic relationship, inheritance
should not be used. Implementations are free to introduce such super classes,
but that is because they are introducing a commonality that the specification
does not require.
Rich
Subbu Allamaraju <subbu@bea.com>
12/14/2004 10:17 AM
|
To
| wsrp@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [wsrp] modifyRegistrationRequired
fault |
|
Andre,
As we discussed earlier, ModifyRegistrationRequired fault is
semantically different from InvalidRegistrationFault, and consumers are
expected to do different things for these faults. IMO, type inheritance
would be confusing in this case.
Subbu
Andre Kramer wrote:
> Depending on how the faults are mapped to exception classes it may
allow
> an implementation to handle any registration faults (using a common
> super type, for example to abort the end user rendering of the faulty
> portlet) and then special case particular extensions of the base
> registration fault behavior (e.g. request an admin to submit a
> modifyRegistration request if that is the concrete fault). But if
no one
> else sees value in expressing this communality then I will drop my
> suggestion.
>
>
>
> Regards,
>
> Andre
>
>
>
> ------------------------------------------------------------------------
>
> *From:* Rich Thompson [mailto:richt2@us.ibm.com]
> *Sent:* 13 December 2004 21:46
> *To:* wsrp@lists.oasis-open.org
> *Subject:* RE: [wsrp] modifyRegistrationRequired fault
>
>
>
>
> 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
>
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]