Re: Optimization Mechanism description (was PASWA Feature Description)

Mark,

I agree there are three layers to transfer optimization, although I
don't necessarily see them as the three deliverables.

The first layer is the abstract feature which specifies a property that
indicates which infoset nodes are to be optimized. I don't like the idea
that this property is just a hint - on the implementation level it
doesn't matter and on the abstract level we have to care about what the
hint-ness of the property means.

The second layer is an inclusion specification that does not include the
Representation and MediaType stuff. This specification splits one
infoset into one XML Infoset part and zero or more generally binary
parts.

The third layer is the HTTP binding that puts all the parts in a MIME
multipart-related package (or other kind of a package).

I see four separate deliverables that I think should be the next product
of the XMLP WG:

1) the abstract feature
2) the HTTP binding (including the inclusion specification which need
not be standalone)
3) the MediaType stuff (carrying generally binary data in XML infoset)
4) the Representation stuff (carrying representations of web resources
in SOAP messages)

Points 1 and 3 only concern XML Infoset; points 2 and 4 actually deal
with SOAP.

I think points 1 and 2 could live in a single document, so I see three
documents to be produced by the current effort based on PASWA.

Best regards,

                   Jacek Kopecky

                   Senior Architect
                   Systinet Corporation
                   http://www.systinet.com/





On Thu, 2003-06-19 at 00:23, Mark Nottingham wrote:
> To kick of e-mail discussion about how this should be layered:
> 
> I think we need three separate deliverables here;
> 
> * optimisation abstract feature
> 
> * an inclusion specification that details the encoding that effects the
> feature in a binding-independent way (i.e., the <include> elements and
> their semantics as well as the Representation stuff; this content would be
> much like the PASWA document). It WOULD NOT specify how the encoding is
> invoked or used (because, to be transport-independent, it would have to
> specify a SOAP module).
> 
> * new HTTP binding - the current HTTP binding + MIME representation +
> optimisation feature implementation. Backwards-compatible with the current
> binding (i.e., messages may be application/soap+xml or they may be
> multipart MIME containing an application/soap+xml).
> 
> Cheers,
>

Received on Wednesday, 25 June 2003 07:46:01 UTC