Re: Tommy's comment on schema extension [ was Re: [dss] [Fwd: Async comments by Tommy] ]

[Tommy Lindberg <tommy.lindberg@gmail.com>]

Hi Andreas -

> I haven't looked at it in detail yet but I can see that you have introduced
> abstract ancestors for both requests and responses - doing the request as
> well, is a nice touch providing symmetry.
Sorry, didn't introduce that much beauty :
There are separate base  types for requests and responses.

Just to make sure that you didn't misunderstand my comment; I thought
that that the way you had refactored the request as well, was a nice
touch :)

> I thought of 'resusing' the RequestID in case it is not given by the requestor.
> This RequestID could be supplied by the client or in certain cases by the server alternatively.

I believe the spec requires the RequestID in a response to match the
RequestID in the request.  Maybe this could be overridden, but a
separate optional attribute (ResponseID) would in my opinion be cleaner.

Slight digression:
The fact that the Asynchronous processing is a profile as opposed to a
part of the core does make the ResponseID a bit awkward alright; it is
unknown if any other profile than the Asynchronous one will ever find
it useful.  I guess an alternative would be an "any attribute" in
the response type as defined in the core and leave the definition of
any additional attributes to the profiles that require them.

Regards,
Tommy

On 9/26/05, Andreas Kuehne <kuehne@klup.de> wrote:

Hi Tommy !

> I haven't looked at it in detail yet but I can see that you have introduced
> abstract ancestors for both requests and responses - doing the request as
> well, is a nice touch providing symmetry.
Sorry, didn't introduce that much beauty :
There are separate base  types for requests and responses.

> However, what I meant in my note was that there should be a *concrete*
> <Response> element and that <SignResponse> and <VerifyResponse> should be
> extended from that concrete element.
As said above there is  'ResponseBaseType' being the ancestor of <SignResponse> and <VerifyResponse>.

> The additional attribute ResponseID should be an optional attribute to the
> <Response> element.
I thought of 'resusing' the RequestID in case it is not given by the requestor.
This RequestID could be supplied by the client or in certain cases by the server alternatively.

Greetings

Andreas


_________________________________________________________________________
Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle
Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179