Minutes, 21 December 2006 WS Description telcon

"Jonathan Marsh" <[email protected]>
Newsgroups gmane.comp.web.services.description
Message-ID <01ae01c7253b$caf069c0$3401a8c0@DELLICIOUS>
enclosed

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com
20061221-ws-desc-minutes.html (text/html, 19.7 KB)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html lang='en' xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
  <meta name="generator" content=
  "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />

  <title>WS Description WG telcon -- 21 Dec 2006</title>
  <link type="text/css" rel="STYLESHEET" href=
  "http://www.w3.org/StyleSheets/base.css" />
  <link type="text/css" rel="STYLESHEET" href=
  "http://www.w3.org/StyleSheets/public.css" />
  <link type="text/css" rel="STYLESHEET" href=
  "http://www.w3.org/2004/02/minutes-style.css" />
  <meta content="WS Description WG telcon" name="Title" />
  <meta content="text/html; charset=us-ascii" http-equiv=
  "Content-Type" />
</head>

<body>
  <p><a href="http://www.w3.org/"><img src=
  "http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
  "48" width="72" /></a></p>

  <h1>WS Description WG telcon</h1>

  <h2>21 Dec 2006</h2>

  <p>See also: <a href=
  "http://www.w3.org/2006/12/21-ws-desc-irc">IRC log</a></p>

  <h2><a name="attendees" id="attendees">Attendees</a></h2>

  <div class="intro">
    <dl>
		<dt>Present</dt>
		<dd>Charlton Baretto, Adobe Systems</dd>
		<dd>Allen Brookes, Rogue Wave Software</dd>
		<dd>Paul Downey, British Telecommunications</dd>
		<dd>Youenn Fablet, Canon</dd>
		<dd>Amelia Lewis, TIBCO</dd>
		<dd>Philippe Le Hegaret, W3C</dd>
		<dd>Jonathan Marsh, Co-chair/WSO2</dd>
		<dd>Monica Martin, Sun Microsystems</dd>
		<dd>Jean-Jacques Moreau, Canon</dd>
		<dd>Gilbert Pilz, BEA Systems</dd>
		<dd>Tony Rogers, Co-chair/Computer Associates</dd>
		<dd>Arthur Ryman, IBM</dd>
		
		<dt>Regrets</dt>
		<dd>Roberto Chinnici, Sun Microsystems</dd>
		<dd>Jacek Kopecky, DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria</dd>
		<dd>Asir Vedamuthu, Microsoft</dd>
      <dt>Chair</dt>

      <dd>Jonathan</dd>

      <dt>Scribe</dt>

      <dd>charlton</dd>
    </dl>
  </div>

  <h2>Contents</h2>

  <ul>
    <li>
      <a href="#agenda">Topics</a>

      <ol>
        <li><a href="#item01">Approval of last week's
        minutes</a></li>

        <li><a href="#item02">Action Item Review</a></li>

        <li><a href="#item03">Administrivia</a></li>

        <li><a href="#item04">CR108</a></li>

        <li><a href="#item05">CR111</a></li>

        <li><a href="#item06">CR114</a></li>

        <li><a href="#item07">CR115</a></li>

        <li><a href="#item08">CR116</a></li>
      </ol>
    </li>

    <li><a href="#ActionSummary">Summary of Action Items</a></li>
  </ul>
  <hr />

  <div class="meeting">
     <h3 id="item01">Approval of last week's minutes</h3>

    <p class='irc'>RESOLUTION:
    approved.</p>

    <h3 id="item02">Action Item Review</h3>

    <pre>[Interop]
?         2006-11-30: [interop] John Kaputin to create a test case 
                      with "required=false". 
?         2006-12-14: [interop] Jonathan to fix transferCodings - 
                      add control group

[WG]
DONE [.3] 2006-10-12: pdowney to review the Schema WG note on versioning 
                      in 1.1.
DONE      2006-12-14: Arthur to examine the equivalence of 0006 and 0014
DONE      2006-12-14: plh to check with XMLP whether they should be 
                      interested in 204 as well
?         2006-12-14: plh to come up with a more detailed proposal for 
                      CR112 if possible

Current Editorial Action Items

Note: Editorial AIs associated with LC issues recorded at [.2].

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/5/cr-issues/actions_owner.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0062.html
    </pre>
    <p class='phone'>pauld: schema 1.1
    - compatibility between it and 1.0 - comment on making that
    more clear</p>
    
    <a name="action01" id="action01"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Jonathan to reference the Versioning
    document in the WSDL Primer [recorded in <a href=
    "http://www.w3.org/2006/12/21-ws-desc-minutes.html#action01">http://www.w3.org/2006/12/21-ws-desc-minutes.html#action01</a>]</p><a name="action02"
    id="action02"></a>

	<p class='phone'><cite>jonathan:</cite> Arthur to examine equiv of 0006 and 0014 - marked as Done</p>

	<p class='phone'><cite>jonathan:</cite> Phillipe to check with XMLP regarding 202/204 return from [robust] one-way requests</p>

	<p class='phone'><cite>philippe:</cite> Don't think this affects HTTP binding, no reason from XMLP group to not use 202/204 as indicated in last week's call</p>
    
    <h3 id="item03">Administrivia</h3>

	<p class='phone'><cite>jonathan:</cite> Administrivia: No telcon next week, resume 1st week of Jan</p>
	<p class='phone'><cite>jonathan:</cite> Postpone databinding review until Jan 04</p>
	<p class='phone'><cite>jonathan:</cite> WSDL 1.1 component indicators - request from Ashok Malhotra to remove direction indicators from message designators, Amy responded that can't do this in WSDL 2</p>
	<p class='phone'><cite>jonathan:</cite> Express a pref on WSDL 1.1. component indicators to keep them consistent with WSDL 2 even though there is redundant info, or to go with the short form even though inconsistent with WSDL 2 indicators</p>
	<p class='phone'><cite>arthur:</cite> Add more MEPs to WSDL 1.1?</p>
	<p class='phone'><cite>jonathan:</cite> No concept of extended MEPs in WSDL 1.1</p>
	<p class='phone'><cite>arthur:</cite> No preference either way; pointed out that the direction indicators are needed for WSDL 2</p>
	<p class='phone'><cite>amy:</cite> Point out that if they want compat with WSDL 2, should keep them consistent</p>
	<p class='phone'><cite>charlton:</cite> +1</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Jonathan to respond to Ashok
    Malhotra/WS-Policy on WSDL 1.1 component indicators [recorded
    in <a href=
    "http://www.w3.org/2006/12/21-ws-desc-minutes.html#action02">http://www.w3.org/2006/12/21-ws-desc-minutes.html#action02</a>]</p>

    <p class='phone'><cite>jonathan:</cite> Note that I have a
    draft [proposal] w.r.t. this area - assume that we will publish
    this, but if you have any comments or feedback, please provide
    to the group<br />
    ... MTOM description - skip over this for today's telcon</p>

    <p class='phone'><cite>monica:</cite> Comment - have you
    considered if more WG members were present so as to publish
    comments on the MTOM policy to the WSP WG?<br />
    ... Interested in the area of simplified policies</p>

    <p class='phone'><cite>jonathan:</cite> Am interested in
    whether profiled policies is the way to go</p>

    <p class='phone'><cite>monica:</cite> Is this Canon's or a
    broader domain concern?</p>

    <p class='phone'><cite>jonathan:</cite> Plausible that one can
    impl a comformant policy process that is fairly straightforward
    - is MTOM in use, and do I support MTOM - is this tractable in
    a constrained device? If those two questions can be answered
    then I don't see the need for profiles<br />
    ... issues</p>

    <h3 id="item04">CR108</h3>

    <p class='phone'><cite>jonathan:</cite> amy and roberto sent
    emails indicating no equivalence<br />
    ... sent an email with his equiv analysis</p>

    <p class='phone'><cite>arthur:</cite> roberto showed we don't
    have a constraint so that assertion 0014 implies 0006<br />
    ... with input element, must be at least one placeholder
    message for the input message, and with output element, must be
    at least one placeholder message for the output message<br />
    ... should explicitly place document level constraints; with
    this i'm fine with eliminating 006</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; scribe: charlton</p>

    <p class='phone'><cite>amy:</cite> I think we're close to
    similar things, with different vocabularies :-); I'm
    comfortable with 006 being removed</p>

    <p class='phone'><cite>arthur:</cite> I want to add four new
    assertions - w.r.t. the placeholder message for direction and
    type</p>

    <p class='phone'><cite>amy:</cite> Why doesn't 2.10.1 cover
    that?</p>

    <p class='phone'><cite>arthur:</cite> Addresses it at the
    component model</p>

    <p class='phone'><cite>amy:</cite> You will eventually fail in
    any case</p>

    <p class='phone'><cite>arthur:</cite> At binding level can't
    have multiple binding messages for a single interface message
    reference; I placed a counterexample where 2.10.1 would fail
    even though the assertions would pass<br />
    ... 2.10 only discussues bindings and interfaces</p>

    <p class='phone'><cite>amy:</cite> In 2.10.1, it is stated that
    interface message is require - must create the property - and
    must bind them uniquely per the assertion.</p>

    <p class='phone'><cite>arthur:</cite> Not saying change 2.10 at
    XML level</p>

    <p class='phone'><cite>amy:</cite> Not suggesting that - but
    what happens is that will have an error if the binding doesn't
    find something that it matches<br />
    ... So what do we gain from adding the 4 assertions?</p>

    <p class='phone'><cite>arthur:</cite> These 4 are document
    level assertions<br />
    ... Input and output don't have direct correspondents at
    component level - we can check them at the document level</p>

    <p class='phone'><cite>jonathan:</cite> New assertions - if we
    add them at the interface, we're ok?</p>

    <p class='phone'><cite>arthur:</cite> Yes<br />
    ... One input in the MEP - at the binding level, can put in two
    input elements - that would be fine w.r.t. constraint on
    message level attribute - but would violate 2.10.1</p>

    <p class='phone'><cite>amy:</cite> Because it happens in the
    binding, yes. But my question is I don't see why assertions on
    the markup are not redundant</p>

    <p class='phone'><cite>arthur:</cite> Markup assertions can
    violate component model assertions</p>

    <p class='phone'><cite>amy:</cite> But the component assertions
    will catch these [eventually]<br />
    ... I don't think that these additonal 4 assertions will change
    the set of documents that will fail</p>

    <p class='phone'><cite>arthur:</cite> You can't even evaluate
    2.10 until you construct the component model</p>

    <p class='phone'><cite>amy:</cite> I understand what Arthur
    want's but don't think the 4 assertions will achieve that</p>

    <p class='phone'><cite>arthur:</cite> Ok, I do think they are
    redundant - but the message you get may be hard to understand,
    so these assertions are general<br />
    ... W/o message label, would be 0012 - but with other 4
    assertions would get a clearer error message for each case</p>

    <p class='phone'><cite>amy:</cite> Should we ask Lawrence
    Mandel for some feedback on the 4 assertions?<br />
    ... We have agreed to remove assertion 006 (and assertion
    004)</p>

    <p class='phone'><cite>jonathan:</cite> Yes</p>

    <p class='phone'><cite>arthur:</cite> If only one message label
    in each direction, don't need to specify it....</p>

    <p class='phone'><cite>amy:</cite> I don't think there's as big
    an issue at it seems - if we can get by without adding
    assertions</p>

    <p class='phone'><cite>jonathan:</cite> Should we add
    assertions that, although providing a better error message, are
    effectively duplicates?</p>

    <p class='phone'><cite>amy:</cite> If we didn't add these 4
    assertions, would there still be a violation in some way?</p>

    <p class='phone'><cite>arthur:</cite> Some assertions don't
    even make sense if others are not satisfied - some are
    pre-conditions for others<br />
    ... Pre-supposition of assertions - implicit pre-conditions</p>

    <p class='phone'><cite>amy:</cite> Agreed - ideally in my
    opinion the spec w/b such that an error would cause one and
    only one assertion to fail</p>

    <p class='phone'><cite>jonathan:</cite> Do we need another
    proposal for these assertions with more detail?</p>

    <p class='phone'><cite>arthur:</cite> You can take my note as a
    recommendation to add the 4 new assertions<br />
    ... Would prefer clear error messages that map to something in
    the WSDL spec when writing a doc</p>

    <p class='phone'><cite>jonathan:</cite> Let's see if we can
    close CR108 by removing assertions 006 and 004<br />
    ... Would like to raise a new issue on adding Arthur's 4 new
    assertions - start email thread on this discussion<br />
    ... No objections</p>

    <p class='phone'>Resolution for CR008 - remove assertions 006
    and 004</p><a name="action03" id="action03"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Jonathan to raise new issue adding 4
    new assertions as per Arthur's note [recorded in <a href=
    "http://www.w3.org/2006/12/21-ws-desc-minutes.html#action03">http://www.w3.org/2006/12/21-ws-desc-minutes.html#action03</a>]</p>

    <p class='phone'><cite>jonathan:</cite> Proposal - in-only
    would raise a 202, robust in-only a 204. XMLP did not have a
    strong opinion on this for HTTP (although they are definitely
    not doing this for SOAP)</p>

    <h3 id="item05">CR111</h3>

    <p class='phone'><cite>jonathan:</cite> Issue is about whether
    we should say what the HTTP return code is for in-only and
    robust in-only cases<br />
    ... Proposal from last week: 202 for in-only and 204 for
    robust-in-only<br />
    ... plh checked with XMLP WG to see if they had a visceral
    reaction - they had none<br />
    ... Any reason anyone would object to using 202/204.</p>

    <p class='phone'><cite>arthur:</cite> Think we need this</p>

    <p class='phone'><cite>charlton:</cite> Don't see a problem
    with it</p>

    <p class='phone'><cite>jonathan:</cite> Any objections to
    adding this?</p>

    <p class='phone'>None</p>

    <p class='phone'><strong class='resolution'>RESOLUTION: Accept
    proposal to use 202 and 204 for in-only and robust in-only MEPs
    in HTTP binding</strong></p>

    <h3 id="item06">CR114</h3>

    <p class='phone'><cite>jonathan:</cite> What would you like to
    see added here, Youenn?</p>

    <p class='phone'><cite>youenn:</cite> Want mapping for robust
    in-only</p>

    <p class='phone'>(section 5.10.4)</p>

    <p class='phone'><cite>jonathan:</cite> You want a section
    5.10.? mapping for in-only and robust in-only to SOAP
    MEPs<br />
    ... Can this be done - for in-only it makes no sense at all</p>

    <p class='phone'><cite>youenn:</cite> No, but for robust
    in-only yes<br />
    ... Makes sense to map in-only and robust in-only MEPs to SOAP
    response MEP<br />
    ... I would like this specified</p>

    <p class='phone'><cite>jonathan:</cite> Adding paragraph, for
    instance, to 5.10.4.1 to talk about in-only and robust
    in-only<br />
    ... Would hope this w/b straightforward<br />
    ... Add desc how to bind in-only and robust in-only WSDL MEPs
    to SOAP request response MEP, taking advantage of 202 in
    PER<br />
    ... Can we close the issue today?</p>

    <p class='phone'><strong class='resolution'>RESOLUTION: Close
    CR114 as per Youenn's proposal</strong></p>

    <h3 id="item07">CR115</h3>

    <p class='phone'><a href=
    "http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR115">http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR115</a></p>

    <p class='phone'><cite>arthur:</cite> Looks fine<br />
    ... Think point is that there are two independent assertions,
    but this is an ex of how one assertion only makes sense when
    the other is satisfied</p>

    <p class='phone'><cite>jonathan:</cite> In other words, the
    target namespaces must match<br />
    ... Proposal to adopt Lawrence Mandel's resolution</p>

    <p class='phone'>No objections</p>

    <p class='phone'><strong class='resolution'>RESOLUTION: Close
    CR115 with Lawrence Mandel's proposal</strong></p>

    <h3 id="item08">CR116</h3>

    <p class='phone'><cite>jonathan:</cite> Constructing request
    IRI - HTTP location template</p>

    <p class='phone'><a href=
    "http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR116">http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR116</a></p>

    <p class='phone'><cite>arthur:</cite> We shouldn't recycle the
    list or throw a runtime error</p>

    <p class='phone'><cite>phillipe:</cite> No value m/b diff from
    empty string</p>

    <p class='phone'><cite>arthur:</cite> prefer empty string
    option<br />
    ... That's how http works - if have form, input field, and no
    value - it shows up as an empty string</p>

    <p class='phone'><cite>phillipe:</cite> Don't like repeating
    value option</p>

    <p class='phone'><cite>arthur:</cite> Neither do i</p>

    <p class='phone'><cite>jonathan:</cite> And nice for us not to
    force runtime errors<br />
    ... Proposal - should have schema s/t have enough elements to
    address token names in template, but if not, use empty string
    for any elements that remain</p>

    <p class='phone'><cite>arthur:</cite> Think a SHOULD for the
    schema w.r.t. elements and templates would be in order<br />
    ... Best practise that things match</p>

    <p class='phone'><cite>jonathan:</cite> Existing assertion is a
    runtime check</p>

    <p class='phone'><cite>arthur:</cite> Can check [otherwise]</p>

    <p class='irc'>&lt;<cite>Jonathan</cite>&gt; Proposal:</p>

    <p class='irc'>&lt;<cite>Jonathan</cite>&gt; 1) Rewrite
    HTTPSerialization-5073 to talk about types rather than
    instances.</p>

    <p class='irc'>&lt;<cite>Jonathan</cite>&gt; 2) Say each token
    SHOULD match something in the instance.</p>

    <p class='irc'>&lt;<cite>Jonathan</cite>&gt; 3) If there is no
    match, replace the token with the empty string.</p>

    <p class='irc'>&lt;<cite>Jonathan</cite>&gt; 4) Repeated tokens
    are replaced by repeated elements in order.</p>

    <p class='irc'>&lt;<cite>Jonathan</cite>&gt; 4) A token may
    appear more than once, in which case it is replaced by
    corresponding repeated elements in the instance.</p>

    <p class='phone'><cite>jonathan:</cite> Any objs to closing
    CR116 with this resolution</p>

    <p class='phone'><strong class='resolution'>RESOLUTION: Adopt
    Jonathan's Proposal as resolution to CR116</strong></p>

    <p class='phone'>Adjourn meeting</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; Scribe: Charlton</p>

    <p class='irc'>&lt;<cite>Jonathan</cite>&gt; yes. I'll add
    that.</p>

    <p class='irc'>&lt;<cite>Jonathan</cite>&gt; Thanks for
    scribing!</p>

    <p class='phone'>you're welcome</p>
  </div>

  <h2><a name="ActionSummary" id="ActionSummary">Summary of Action
  Items</a></h2><!-- Action Items -->
  <strong>[NEW]</strong> <strong>ACTION:</strong> Jonathan to raise
  new issue adding 4 new assertions as per Arthur's note [recorded
  in <a href=
  "http://www.w3.org/2006/12/21-ws-desc-minutes.html#action03">http://www.w3.org/2006/12/21-ws-desc-minutes.html#action03</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Jonathan to
  reference the Versioning document in the WSDL Primer [recorded in
  <a href=
  "http://www.w3.org/2006/12/21-ws-desc-minutes.html#action01">http://www.w3.org/2006/12/21-ws-desc-minutes.html#action01</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Jonathan to
  respond to Ashok Malhotra/WS-Policy on WSDL 1.1 component
  indicators [recorded in <a href=
  "http://www.w3.org/2006/12/21-ws-desc-minutes.html#action02">http://www.w3.org/2006/12/21-ws-desc-minutes.html#action02</a>]<br />

  &nbsp;<br />
  [End of minutes]<br />
  <hr />

  <address>
    Minutes formatted by David Booth's <a href=
    "http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
    scribe.perl</a> version 1.127 (<a href=
    "http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br />
    $Date: 2006/12/21 19:20:43 $
  </address>

</body>
</html>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.