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

[Andreas Kuehne <kuehne@klup.de>]

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.
>
> 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  about introducing a  top level  'CommunicationElement'  
introducing the things included both in Request and Response ... but 
then remembered the goal of keeping the core simple and left the 
creation of beauty to my wife.

> > 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.
>
The definition of ResponseID in the core wasn't introduced by the async 
profile. The intention was ( iirc ) to related requests / responses 
together if the transfer protocol didn't .
This is not so far away from what's needed in async, but I wouldn't mind 
to introduce another attribute to correlate the different async 
messages. But this should be done in the async profile. Again, for the 
sake of a simple core, let' keep this out.

Greetings

Andreas

> Regards,
> Tommy
>
> On 9/26/05, *Andreas Kuehne* <kuehne@klup.de <mailto: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 <http://WEB.DE> FreeMail können Sie
>     eine SMS an alle
>     Freunde gleichzeitig schicken:
>     http://freemail.web.de/features/?mc=021179
>
>
>
>