RE: Indicating element nodes that must be optimized with XOP

Hi Hugo,

Regarding your "XOP-optimization required" value, what would the
behavior be in the following cases?

1) The run-time value of the element is not in canonical lexical
representation (so that, according to XOP, it cannot be optimized)

2) The XOP machinery decides not to optimize the element for its own
reasons (which is consistent with the XOP Processing Model).

Regards,
Ugo

> -----Original Message-----
> From: Hugo Haas [mailto:hugo@w3.org] 
> Sent: Tuesday, June 01, 2004 7:20 AM
> To: Ugo Corda; Herve Ruellan
> Cc: www-ws-desc@w3.org
> Subject: Re: Indicating element nodes that must be optimized with XOP
> 
> 
> 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/
>

Received on Tuesday, 1 June 2004 13:25:54 UTC