Both being registration related faults is
a semantic relationship.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 15 December 2004 13:50
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp]
modifyRegistrationRequired fault
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.