RE: fault serialization

Thanks for your comment.  The WS Description Working Group tracked this
as a Last Call comment LC337 [1].  The Working Group agreed to fix the
problem in the following manner:

 - Copy the content of section 2.2 of the Describing Media Types for
Binary Content note (a product of this WG) into part two,

 - point the definition of whttp:inputSerialization,
whttp:outputSerialization, and whttp:faultSerialization at that

 - check other references to these serialization properties to insure
that they do not improperly restrict serialization to a single mime

The net effect is that you will be able to specify alternative media
types in the whttp:*serialization attributes.

If we don't hear otherwise within two weeks, we will assume this
satisfies your concern.


> -----Original Message-----
> From: [mailto:public-ws-desc-
>] On Behalf Of Kendall Clark
> Sent: Wednesday, September 14, 2005 8:44 AM
> To:
> Cc: Dan Connolly
> Subject: fault serialization
> WS-Desc,
> I'm writing on behalf of DAWG, which is using WSDL 2.0 to specify the
> Protocol for RDF [1]. We have a couple of LC comments about WSDL 2.0,
> and
> I'll be sending each one in a separate message.
> We'd like to avoid having to require a particular fault serialization
> type
> in our HTTP bindings. That is, we anticipate SPARQL services being
> free to
> serialize fault messages in several different Media Types: plain text,
> XML, RDF, etc.
> If whttp:faultSerialization is a required property and the default
> value
> doesn't describe our service, what alternative do we have?
> Hugo Haas responded to my initial comments thus:
>   Maybe the fault serialization should be a property of the Binding
> Fault
>   and Binding Fault Reference components, rather than of the Binding
>   Operation, which would solve your problem.
> There may be other design choices as well.
> Cheers,
> Kendall Clark
> [1]
> --
> In times of universal deceit, telling the truth is a revolutionary
> act.
> 					  --George Orwell

Received on Wednesday, 5 October 2005 20:57:50 UTC