- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Mon, 24 Jun 2002 10:25:46 +0200
- To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- CC: "WS-Desc WG (Public)" <www-ws-desc@w3.org>
Hi Sanjiva, My initial reaction is to say no, the abstract model should not be coupled to the infoset. But then I am wondering what does this really means. Is the difference only in terms of terminology ("property" vs. EII?) or is it more profound? Wouldn't both approaches essentially model a (DOM) tree? Isn't the infoset already a suitable model? The cut we have done for SOAP 1.2 is to describe the semantics/processing [1] separate from the syntax [2]. Would a similar model work for WSDL? Taking a specific example from your latest draft -section 2.2 [3]-, would it work to keep to keep only paragraph 1 and move the rest to section [3], whilst adding a longer description of what a message represents? I realize I am raising more issues than providing answers... What do you think? Jean-Jacques. [1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#msgexchngmdl [2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#soapenv [3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/part1/part1.html#message-desc-component Sanjiva Weerawarana wrote: > <snip/> I was wondering where the > semantics go .. in the abstract description or at the point of > describing the infoset for each description component? > > I wonder whether we should drop the "be infoset based" requirement > now that we have are abstract model based. I kind of like the > infoset description approach (I cut-n-pasted from the soap spec > to get the template; thanks to whoever wrote that part!), but it > does seem a bit redundant. > > <snip/> > > * Re. "property". Shouldn't this be EII or AII in a number of places? > > I didn't think the abstract model should be coupled to do the infoset. > Do you? EII/AII implies a specific serialization .. one can imagine > more than one serialization (infosets) of the same abstract model.
Received on Monday, 24 June 2002 04:26:18 UTC