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

* Amelia A Lewis <alewis@tibco.com> [2005-10-25 12:42-0400]
> I find both of the first two options a little frustrating.  They look a
> bit like overkill.

Agreed.

> >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.

As one can always override anything with extensions, I had left this
comment out, but that's correct.

> [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 ...).

Agreed. SVG could still be used, as it's XML-based. One would use
whttp:outputSerialization="image/svg+xml" and the instance data, which
will be SVG, will be serialized with the rules of application/xml.

> 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.  

Yes, if they want to use a non-XML based format, they'll need an
extension.

> 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?

I personnaly think that it's an OK limitation so late in the game. In
any case, if somebody wanted to describe the sending of binary data,
they would need to come up with an extension anyway, and this with any
option we pick, as we don't support non-XML data out of the box.

Cheers,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/