W3C

- DRAFT -

WS Description WG telcon

1 Feb 2007

See also: IRC log

Attendees

Present
hughesj, Jonathan_Marsh, Arthur_Ryman, Plh
Regrets
Chair
Jonathan
Scribe
scribe-jjm

Contents


 

 

Implementer's call

<plh> Namespace qualified elements tend to produce messages whose interpretation is less ambiguous than those with unqualified elements. The use of unqualified elements is therefore discouraged.

<jjm> nick scribe-jjm

<jjm> Minutes approved

One-Way SOAP

<jjm> Jonathan: JJ, do you prefer to send your comments yourself or through the WG?

<jjm> JJ: the latter sounds good to me.

<jjm> Jonathan: ok, sent.

WSDL 1.1 identifiers

<jjm> Jonathan: any comments?

<jjm> Arhtur: I reviewed an earlier draft?

<jjm> Jonathan: do you want to see if any was broken since you last looked?

<charlton> WSDL 1.1 element identifiers document published by WS-Policy WG:http://www.w3.org/TR/wsdl11elementidentifiers/

<jjm> ACTION: Arthur to review the WSDL 1.1 identifier spec [recorded in http://www.w3.org/2007/02/01-ws-desc-minutes.html#action01]

<jjm> nick scribe-jjm

Issue 145 (cont'd)

Jonathan: we were about to limit the scope last week but wanted Arthur's position
... also, I've proposed an amendment

Roberto: I like it
... would prefer that the namespace be explicitely mentionned

Arthur: is it clear enough for you to implement?

Jonathan: can you not confirm that yourself?
... my stylesheet implement has limits as to its exploring depth

Arthur: in the type section, if see a schema or xs:import, those components get included

Roberto: true for WSDL include

Arthur: not WSDL import (namespace issue)?
... the only things we exclude are xs:import in an included schema
... edge case: we allowed top level xs schema with no top level namespace (issue 45)
... so, we would include those components
... they would all endup in the global no-namespace schema
... so non ambiguous

Roberto: I agree

PROPOSAL: Roberto's proposal amended by Jonathan email from 31/1/7, plus some editorial license

RESOLUTION: Roberto's proposal amended by Jonathan email from 31/1/7, plus some editorial license

Issue 117

Jonathan: a bit controversial last week

Jacek: even if we use the flag, it would not go to LC

Jonathan: I would be prepared to argue that; don't want to go back to LC

Philippe: it is a change, no doubt, by the letter would have to go to LC, but negative reactions are likely to be low, so would support this option in front of the director

JJ: would prefer to hold resolution until Youenn is back next week

Jonathan: ok, but would like to continue discussion a little bit so we weed out the options
... don't like options which don't allow people to %-escape things if they wish
... what are people's preferences?

Jacek: 3 options: 1. no encoding; 2. full encoding; 3. partial encoding
... 1. no option for Jonathan
... 2. not an option for some
... so 3. looks like the easy option

Jonathan: citing a parameter allows it's name to be changed; this is orthogonal to escaping
... often I would like to be able to encode
... option 1 (as per the agenda, not Jacek's above) sounds better to me

<Roberto> +1 for option 1 in the agenda

STRAWMAN: option 1 (from the agenda)

Jonathan: I suggested a syntax; but the default should be encoded; so # before a token to indicate raw instead
... amenable to using a bracket instead
... which character should be encoded? In my proposal for option 3, very restricted. Maybe I should...

<scribe> ACTION: Jonathan to provide an enhanced option 1 for issue 117 by next week, using bits from the other proposals as indicated above [recorded in http://www.w3.org/2007/02/01-ws-desc-minutes.html#action02]

Issue 143

Philippe: should use Transfer-encoding instead of Content-encoding

Jonathan: wonder if Dave Orchard thought about other uses than zip

Philippe: Transfer-encoding is a section in the HTTP spec, so covers both

Jonathan: should go to Transfer-coding header
... close today by moving to Content-encoding; or leave it open whilst getting feedback
... would rather close this sooner since reason for many reds in tests
... but a week is reasonnable

Philippe: we could use identity instead

Jonathan: JJ, you don't support gzip as I recall?

JJ: correct

Jacek: does the header have to be present, though? I suspect not

<plh> [[ If the content-coding of an entity is not "identity", then the

<plh> response MUST include a Content-Encoding entity-header

<plh> (Section 14.11) that lists the non-identity content-coding(s) used. ]]

Jonathan: have to stick with gzip and accept some of our tests fail

Issue 135

Jonathan: proposal for a new feature, has to do with operation dispatch, related to a former issue using http-location to dispatch
... so, generic binding and HTTP bindings don't work well together
... hence propose location-default property

PROPOSAL: close with no action

RESOLUTION: as just proposed

Issue 144

Jonathan: add {http location ignore uncited} parameter

Arhtur: how many will we need to add?

Jonathan: this one for now; there's a concrete proposal

Arthur: ok

RESOLUTION: adopt the proposal in the my email

Issue 146

Jonathan: {http location ignore uncited} and required schema data
... required information may be dropped
... proposal is that if uncited, should be nillable

Arthur: don't quite like nillable

Jonathan: would prefer optional; but if nillable can still operate

<Jonathan> http://lists.w3.org/Archives/Public/www-ws-desc/2007Jan/0208.html

Arthur: would be ok if using min/maxoccurs

Jonathan: this is my amendment from this week

Asir: nillable is for the content

Arthur: here, if not being sent, but declared in schema as nillable, proposal is to reinsert the element and get a value nil=true
... is that equivalent to missing value for optional element?
... let's say instead element required, but is not present and has a default value

Asir: the infoset gets augmented with the default value
... it gets added when the element is present and doesn't have content

Robertor: value can only be characters

Jonathan: so add or has to have a default
... property must be defined as nillable, or has a default value, or has minoccurs=1

Arthur: we should check default further in the schema spec
... if element missing and has minoccurs=0, don't reconstitute
... if minoccurs=1 and default value, reconstruct
... would like a deterministic rule, needed for interop
... should say what we get after reconstruction

Jonathan: constraint: can mark both as nillable and have a default value

Arthur: maybe in schema spec already ;-)

Asir: from spec, if nillable, no other constraint

Jacek: from different section: if nillable, and not here, it's nil. If not nillable, and not there, default.

<Roberto> karnaugh map

Roberto: let's take this to the list

ADJOURN

Summary of Action Items

[NEW] ACTION: Arthur to review the WSDL 1.1 identifier spec [recorded in http://www.w3.org/2007/02/01-ws-desc-minutes.html#action01]
[NEW] ACTION: Jonathan to provide an enhanced option 1 for issue 117 by next week, using bits from the other proposals as indicated above [recorded in http://www.w3.org/2007/02/01-ws-desc-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2007/02/01 17:53:56 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.127  of Date: 2005/08/16 15:12:03  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/WH/WG/
Succeeded: s/)/)?/
No ScribeNick specified.  Guessing ScribeNick: scribe-jjm
Inferring Scribes: scribe-jjm
Default Present: hughesj, Jonathan_Marsh, Arthur_Ryman, Plh
Present: hughesj Jonathan_Marsh Arthur_Ryman Plh
Got date from IRC log name: 1 Feb 2007
Guessing minutes URL: http://www.w3.org/2007/02/01-ws-desc-minutes.html
People with action items: arthur jonathan

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]