Re: Optimization Mechanism description (was PASWA Feature Description)

> The first layer is the abstract feature which specifies a property that
> indicates which infoset nodes are to be optimized.

Agreed.

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

Optimisation by its nature is optional, therefore it's more sensible (and
flexible, forgiving, and potentially efficient) to make it a declarative
hint rather than an imperative processing instruction.

For example, HTTP caching isn't required, it's only advisory; many people
lament the fact that you can't force a cache to keep something, but
arguably caching would never have taken off if it had been required.


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

That's one way to characterise it, yes.


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

Agreed - as long as it still allows application/soap+xml!


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

It sounds to me like people want to be able to use inclusion in other
underlying transports, which argues for making it separable.


> 3) the MediaType stuff (carrying generally binary data in XML infoset)

FWIW, I'd characterise this as leveraging the internet media type system
within XML.


> 4) the Representation stuff (carrying representations of web resources
> in SOAP messages)

This is especially interesting. I don't think it's necessarily
SOAP-specific...

Cheers,

Received on Tuesday, 1 July 2003 13:01:41 UTC