Re: Indicating element nodes that must be optimized with XOP

Hi Hugo, Ugo et. al,

IMO the required / optional aspect needs to be driven by, whether is the 
optimization feature itself is required or optional.
At the element level all we need is a flag that indicates, if the 
serialization is optimized then the elements tagged are to be part of it 
(from the server perspective). Need to specify this @ only when true. 
False is default when this flag is not present on an element.

As an aside putting this flag on element definition (and not at the 
binding level) is perhaps not great, but I am not sure the alternatives 
would be simple.

Regards, Prasad


-------- Original Message --------
Subject: 	Re: Indicating element nodes that must be optimized with XOP
Date: 	Tue, 1 Jun 2004 07:19:20 -0700
From: 	Hugo Haas <hugo@w3.org>
To: 	Ugo Corda <UCorda@SeeBeyond.com>, Herve Ruellan 
<herve.ruellan@crf.canon.fr>
CC: 	www-ws-desc@w3.org


Hi Ugo and Herve.

* Ugo Corda <UCorda@SeeBeyond.com> [2004-05-29 16:57-0700]
> > The values of xop:optimize could be false or true, true 
> > meaning that if a XOP is used, e.g. with the HTTP 
> > Transmission Optimization Feature, the element node must be 
> > optimized, false being the default value and leaving it up to 
> > the sender to decide whether to optimize or not an element node.
> 
> I suggest that the xop:optimize attribute be just a hint for the
> optimization engine. 
> 
> According to the current description of the XOP Processing Model, when
> XOP is applied to the message transmission the XOP run-time takes
charge
> of identifying the candidates for optimization (see sec. 4.1, step 4).
> So I think that saying that xop:optimize provides a hint to the XOP
> run-time is the correct way of relating to the XOP spec.
[..]

* Herve Ruellan <herve.ruellan@crf.canon.fr> [2004-06-01 14:20+0200]
> Here are some answers for your questions (note that I speak for myself

> and not on behalf of the XMLP WG).
> 
> Hugo Haas wrote:
> <snip/>
> >The issue we have left as we discussed yesterday in our telcon is to
> >identify which elements node to be optimized as per step 4 of the XOP
> >processing model[7].
> 
> Note that saying nothing about how elements node to be optimized are 
> identified is a deliberate choice of the XMLP WG. The purpose is to
let 
> applications free of choosing the mechanism best suited to them.

In a WSDL document, there will be descriptions of messages. Those
messages will contain a set of element nodes that a Web service agent
may optimize with XOP, if the binding allows it.

The question on the table is: what do we want to indicate with regards
to XOP optimization, if anything?

Herve says that the XMLP WG chose not to specify it to let
applications do the choice themselves. Ugo talks about providing a
hint, and I came up with a use case where an agent would require
another to use XOP optimization.

Maybe we can have a marker on those element nodes which has three
values: XOP-optimization required, XOP-optimization
hinted/recommended, no claims made (default).

In any case, I think that an agent can always optimize additional
things that it wants.

Herve, is it in the spirit of what the XMLP WG wanted to do with XOP?

> <snip/>
> 
> >An interesting thing I realized is that XOP itself is not a feature,
> >i.e. the HTTP Transmission Optimization Feature uses XOP (which is
> >only specific to SOAP despite its name) but doesn't say it's using
the
> >XOP feature, with a URI, etc.
> >
> >It would be cool to have the HTTP Transmission Optimization Feature
> >say that it uses the XOP feature, and then if somebody defines the
XML
> >over HTTP Transmission Optimization Mechanism feature as per my
> >previous email[8], the feature could say that it uses the XOP feature
> >and then it would be clear when the xop:optimize attribute becomes
> >relevant.
> 
> XOP is not a SOAP feature, but a packaging mechanism that can be used
by 
> any XML language (there are some interests from SVG for using it).
>
> However for the purpose of identifying a generic SOAP feature of which

> the HTTP Transmission Optimization Feature is a specialisation, MTOM 
> defines the Abstract Transmission Optimization Feature [1] that is 
> identified by a URI.
[..]

I had missed that one, thanks. Reading this, I think that all I was
after in defining a XOP feature was having a normative reference to
XOP in the specification of a feature building on top of XOP, so I
don't think there's an issue here after all.

Regards,

Hugo

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