Re: [LC304] Proposal for specifying serializations using two properties: serialization format, and content type

On Tue, 25 Oct 2005 17:57:22 +0200
Hugo Haas <hugo@w3.org> wrote:

[snipped lots]

I find both of the first two options a little frustrating.  They look a
bit like overkill.

>So maybe there's a third option, as I'd really like to find a simple
>fix.
>
>As we are defining messages based on an Infoset data model, our
>instance data is an XML blob.
>
>We could keep the input serialization property to be what a list of
>media type tokens, and define its content as indicating the content
>type to use on the wire.
>
>If the content type used is application/x-www-form-urlencoded, then
>our rules for the application/x-www-form-urlencoded serialization
>format are used.
>
>If the content type used is multipart/form-data, then our rules for
>the multipart/form-data serialization format are used.
>
>If the content type used is application/xml, then our rules for the
>application/xml serialization format are used.
>
>If another content type is used, then we use the rules from the
>application/xml serialization format, and set the content type to the
>appropriate format.

I like the (relative) simplicity of this option.  It also seems to be
approximately what our original intent was.

I think this last para should be: must use the rules from
application/xml, unless an extension defines different rules.

[snipped example]

>The limitation for this third solution would be that one cannot
>serialize say image/png without a WSDL extension. Also, one could not
>come up with say another application/x-www-form-urlencoded
>serialization format without a WSDL extension or another HTTP binding.
>But that would be the simplest fix I see, and I'm all for moving
>forward with the smallest set of changes.

Hmm.  I don't see the inability to serialize image/[whatever] as a
significant drawback, considering the complexity involved in
serializing as such (svg, maybe, but ...).

So: the restriction is that, if our serialization formats are limited
with regard to some application's needs, then they can't replace our
format with one that suits them, for a given content-type.  

How likely is that scenario?  Are there obvious limitations to any of
our defined formats?  Are there more subtle limitations?  Is there an
example of something that *can't be done* if we define things in this
fashion?

Amy!
-- 
Amelia A. Lewis
Senior Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 25 October 2005 16:42:48 UTC