See also: IRC log
<anish> Scribe: anish
c. Action Item [3] Review:
PENDING 2005-06-16: Amy to provide test cases for MEPs not described
in Part 2, due 2005-07.
PENDING 2005-07-21: pauld to write a proposal for a working group
report for requirements for schema evolution
following closure of LC124
DONE 2005-09-22: Hugo to present a proposal for LC323,
due 2005-09-26.
RETIRED 2005-09-22: Glen will look at LC339 and LC340, due 2005-09-26.
PENDING 2005-09-22: Marsh will look at section 5.6 in relation to IRI,
due 2005-09-26.
PENDING 2005-09-22: Glen will reword sentence in 5.9.1,
due 2005-09-26.
JM: few people expressed interest
Roberto: Sun may be able to do it
<more discussion on Jan F2F>
JM: east coast would be great
... candidates -- week of 16th or 23rd
... we should think about our agenda for the jan f2f, perhaps a interop bakeoff
<pauld> IBM / Axis Wave / Particle duality discussion
JM: another option is to not have a full WG meeting, but go thru the test cases
Sanjiva: distributed meeting may make sense in that case
JM: we may be able to go to CR before Tokyo F2F
no decision on jan f2f. Few options. Decision will be made later
Jonathan: i18n is going to be 3 weeks late on sending comments
proposal from Hugo: http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0037.html
Hugo explains his proposal
<hugo> <whttp:header name="foo" type="bar:foobar" />
<hugo> <whttp:header element="bar:foo" /> <- proposal 2
Tom: like proposal 1, but not restricted to simple types
<hugo> "{type}, REQUIRED." should have: "This type MUST be a simple type."
<TomJ> using element in this context is wacky
anish: concerns about proposal 1 -- reminds of rpc/encoded
tom: there is some text (from proposal 2) that needs to be included in proposal 1
... need to make it clear that we are serialization the value and not angle brackets
JM: proposal 1 with 2 amendments --
<TomJ> If we can use the words lexical or string representation to make clear there are no angle brackets in the value
1) make it clear that the types are restricted to simple types
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0017.html
2) If we can use the words lexical or string representation to make clear there are no angle brackets in the value
Jacek's concern -- http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0017.html
Jonathan: we could write the schema to restrict the length of name
Jacek: we should say that the values (at runtime) described by the type must not contain values that are disallowed
Tom: to reiterate the proposal -- we include the limitation on the length of the header, for values we reference the relevant RFCs
arthur: in addition our schemas should enforce that (for the name of the header)
<Zakim> hugo, you wanted to ask about the ASCII restriction
hugo: don't dislike tom's proposal too much
<Arthur> in general, our spec should refer to definitions from other specs instead of copying the definitions
<Arthur> our schema should enforce as much as it can
<hugo> [[
<hugo> The TEXT rule is only used for descriptive field contents and values
<hugo> that are not intended to be interpreted by the message parser. Words
<hugo> of *TEXT MAY contain characters from character sets other than ISO-
<hugo> 8859-1 [22] only when encoded according to the rules of RFC 2047
<hugo> [14].
<hugo> TEXT = <any OCTET except CTLs,
<hugo> but including LWS>
hugo: tom's proposal does solve the problems and we should remove any mention of UTF8
<hugo> ]]
<hugo> [[
<hugo> message-header = field-name ":" [ field-value ]
<hugo> field-name = token
<hugo> field-value = *( field-content | LWS )
<hugo> field-content = <the OCTETs making up the field-value
<hugo> and consisting of either *TEXT or combinations
<hugo> of token, separators, and quoted-string>
<hugo> ]]
Tom: we have 2 amendments for Hugo's proposal 1 + include the desc of how to make a HTTP name (Jacek's email) and we put that in our schema + for the value of the header we reference the HTTP specs and say that this has to be followed
JM: plus we need to remove UTF8
... we have a new property called 'type', should we call it 'simpleType'
arthur: we should call it 'type definition' rather than 'simple type'
JM: any objections to the proposal with the 4 (or 4.5 amendments)?
arthur: if we have qname references to types what happens if it is a buildin type?
... it has to be a definition of a schema type definition component
glen: then every builtin type has a type component definition
arthur: worried about how things get parsed
... we don't have an import for builtin types
umit: i think it is irrelevant
... i don't think we should go there.
JM: addition of a sentence regd this would solve the problem
... arthur can you look at this and raise an issue if this is a problem
<scribe> ACTION: Arthur to figure out how to treat builtin schema types [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action01]
roberto: the status right now is you create a lexical representation, then you encode it as utf8 and then check whether there is a problem?
amy: the rfc says utf 8 (rfc 2822)
... nothing to gain by transforming to utf8
... the http spec says iso-8859-1 not utf8
JM: we agree to remove the words: "in utf8" from hugo's proposal 1
... any objections to adopting proposal 1 with all the amendments
<no objections>
Issue LC315 is closed
... 315 closed with Hugo's proposal 1 with various amendments
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0011.html
tom: like it
sanjiva: +1
JM: any objections to accepting Asir's proposal?
no objections
RESOLUTION: 321 closed with Asir's proposal
JM: do we have a close enumeration or extensible
<TomJ> wouldnt it be ok to leave it alone and allow other values?
JM: any objection to closing issue 326 with Hugo's proposal?
no objection
RESOLUTION: LC326 resolved with Hugo's proposal
20 minute break
-------------------------------
back
back from the break
proposal from hugo -- http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0012.html
JM: any objection to the proposal?
no objection
RESOLUTION: LC319 resolved with hugo's proposal
Glen: when u see a soap header decl, do i have to send one, or two etc. If you see the Qname of the header you know the spec. If the spec says that the header is to be sent only between 3pm and 5pm then you know what to do. OR have a minOccurs/maxOccurs
sanjiva: this is a slippery slope to having a 'message' structure
<Zakim> hugo, you wanted to propose not to change anything
hugo: this is a nice feature to have but we want to be done
... so we don't change it
<hugo> http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#soap-defaults
<hugo> "If the {soap headers} property as defined in section 5.10 Declaring SOAP Header Blocks exists and is not empty in a Binding Message Reference or Binding Fault component, element information item conforming to the element declaration of a SOAP Header Block component's {element} property, in the {soap headers} property, MUST be turned into a SOAP header block for the corresponding message."
anish: why don't we add what we already have for wsoap:module
JM: can we say if you see wsoap:header then it is exactly 1 (cardinality
... )
<more discussion on cardinality of headers>
davidO: only interested in 0 or 1. not interested in > 1
glen: change the text to say zero or one
JM: resolution to replace "Zero or more such headers may be used." to "Zero or more headers may be used".
... resolution to replace "Zero or more such headers may be used." to "Zero or one headers may be used".
sanjiva: it may be clearer to say header blocks may or may not appear on the wire. But this is editorial
daveo: replace header/header block
<dorchard> Zero or one such header blocks may be used
JM: for LC340 correct the plural, replace 0 or more with 0 or 1 + editorial
... for LC339 we say that it is 0 or 1 and if you want more use modules
roberto: this is a burden -- to write a module spec and get interop
glen: we could reuse the 'required' attribute (no NS) -- same as wsoap:module
<JacekK> oh, if it had html media type 8-)
anish: are folks (like WSS TC) defining soap modules
sanjiva: no, but a module is not enuf for WSS, you need more like policy
JM: we are talking about adding a 'required' attribute similar to wsoap:module and a 'required' property. Default of 'false'. required='true' sets the required property to true.
<sanjiva> actually, module is enuf because that's really just another way of asserting a policy .. what I said is having 1..n wsoap:header things is not enough.
JM: when 'true' it means that the service expects the header to be there.
... if 'false' then the sender decides whether it should be there or not
(the above is a resolution for issue LC339)
hugo: this is a new feature
... we also need to talk about the http header -- we have changed the syntax
<sanjiva> I disagree this is a new feature - we already have this capability if one is using wsoap:module, all we're doing it is increasing the convenience of the wsoap:header hack.
JM: is this a significant new feature that would impact going to CR after this?
sanjiva: this is not a new feature, we already have this in wsoap:module
glen: we are adding new functionality
JM: hugo do we need to go back to LC for this feature
hugo: that is a difficult Q to answer, we have to answer -- have we made a change this is significant and invalidate reviews. I don't think anybody would see this functionality and scream. I don't think this would force us to go back to LC.
JM: anybody else think that way?
daveo: i agree with hugo
anish: i agree with hugo
<sanjiva> +1
JM: ok, what I'm hearing is that this won't force us to go back to LC
... we also need to talk about changes to HTTP header
... any complexity in transfering this feature to the HTTP binding?
... proposal to add the required attribute (and all the component stuff) for wsoap:header AND http header
... any objections
no objections
RESOLUTION: issue LC339 and LC340 resolved with the above proposal
<Roberto> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0046.html
Bijan presents http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/att-0046/wsdl-rdf.html__charset_ISO-8859-2
slide of the presentation: http://lists.w3.org/Archives/Member/w3c-ws-desc/2005Sep/0016.html
<Arthur> Jack said that there is no need for the Description component, however I think it is important since it acts as a container for all the top level components in a component model instance
Issue -- spec simplification about content type
arthur: media-type is irrelevant for this
bijan: the issue is if you have a frag identifier, do you need the media type?
daveo: u don't have to have the media type
... u can guess
Everyone (who were paying attention) agree that this is not an issue
<dorchard> I now know the key phrases to listen for when talking about frag-ids and URIs "then you get the media type to interprent the frag-id" bzzzzt.
JM: the question is -- how do we get a broad review of this. One needs a good understanding of RDF and OWL to do this.
... how do we engage the right people to review this?
... let's do that after lunch
Jacek: can we do this tomorrow?
LUNCH
----------------------------------
Jonathan explains the issue: inconsistency in being required and defaulting to ""
Arthur: explains the diff between being required in the component model and having a default value for it which means it may not have to be in the XML.
Sanjiva: this is how it should be in this case ..
Amy: if there is an auth scheme then there is a realm always. Therefore its correct as it stands.
Amy: Its possible to configure a server to have "" as the realm of an auth.
Hugo: proposes to make the property be optional.
Amy: Why do u want to remove the "" default value?
Hugo: Likes to think that props in the component model are props that are needed. If there is no auth scheme then having the property around is unnecessary.
Sanjiva: Hugo's proposal is to clean up the case of having an unused property when auth scheme is none.
Arthur: Notes that {http authentication scheme} is required. Therefore treating the special value "none" with a special rule for realm makes sense.
... So the option could be to make both optional, drop "none" as a value for scheme and follow the logic thru.
Amy: +1s it
<uyalcina> +1 to Arthur's proposal
Jonathan: Notes that in other cases we've made an effort to have a value to indicate no value .. hence the token "none".
Arthur: points out that we're not overloading the situation - so its an easy cleanup
Jonathan: PROPOSAL:
... 1. make auth scheme and realm both optional
... 2. auth scheme and auth realm properties exist together
... 3. drop the value "none" from auth scheme values
... 4. we use the default value of the attribute to provide the default value for realm (of "")
Roberto: Suggests cleaning up the component model by introducing an http authentication component with two properties (schema and realm)
Amy: +1
Arthur: getting perverse, suggests that the component model could be object oriented much better
Roberto: Notes that the Zee (or was it Zed) would be too hard to handle that case.
<charlton> +1 to the proposal
Chad: wake up
Straw poll:
<Roberto> chad, invite
.. 1: make a new component with two props
... 2: cleaned up two properties (co-dependent as proposed earlier)
.. 3: single property which is a pair of strings
Anish: impact w.r.t. CR?
Jonathan: No syntax change so its fine
<alewis> chad, new poll
<chad> new poll
Arthur: For consistency, every component in part 1 corresponds to an element
... the proposed option 1 breaks that consistency.
<alewis> chad, question: which of the following solutions is preferred to solve the inconsistency in description of http auth scheme/realm?
<alewis> chad, option 1: make a new component with two properties
<alewis> chad, option 2: clean up the two properties (make them co-occurrent and optional)
<alewis> chad, option 3: create a single property which contains two values, both strings
Umit: what's the cost of these options?
Jonathan: None of these changes the syntax .. so its "low cost"
<alewis> chad, option 0: close with no action
<Marsh> chad, options?
<dorchard> vote: 1
<Arthur> vote: 2, 1, 0
<Roberto> vote: 1, 2, 0
<bijan> vote: 3
<uyalcina> vote: 2, 1, 0
<TonyR> vote: 2, 1
<RebeccaB> vote: 1,2,0
<Allen> vote: 2
<alewis> vote: 1, 2
<pauld> vote: 1
<sanjiva> vote: 2,0
<kliu> vote: 2, 0
<charlton> voteL 1, 2, 0
<hugo> vote: 2, 0, 1
<charlton> vote: 1, 2, 0
<Marsh> 3, 2, 0
<Marsh> vote: 3, 2, 0
<Marsh> chad, count
<chad> Question: which of the following solutions is preferred to solve the inconsistency in description of http auth scheme/realm?
<chad> Option 0: close with no action (0)
<chad> Option 1: make a new component with two properties (6)
<chad> Option 2: clean up the two properties (make them co-occurrent and optional) (7)
<chad> Option 3: create a single property which contains two values, both strings (2)
<chad> 15 voters: alewis (1, 2) , Allen (2) , Arthur (2, 1, 0) , bijan (3) , charlton (1, 2, 0) , dorchard (1) , hugo (2, 0, 1) , kliu (2, 0) , Marsh (3, 2, 0) , pauld (1) , RebeccaB (1, 2, 0) , Roberto (1, 2, 0) , sanjiva (2, 0) , TonyR (2, 1) , uyalcina (2, 1, 0)
<chad> Round 1: Count of first place rankings.
<chad> Round 2: First elimination round.
<chad> Eliminating candidadates without any votes.
<chad> Eliminating candidate 0.
<chad> Round 3: Eliminating candidate 3.
<chad> Candidate 2 is elected.
<chad> Winner is option 2 - clean up the two properties (make them co-occurrent and optional)
<Roberto> chad, details
Jonathan: is option 2 good enough to go forward with?
Consensus achieved!
<dorchard> BC STV apparently didn't get very high score on the "litres/100km" rating.
<charlton> agreed
Editorial AI: clean up the wording of the "Relationship to WSDL Component Model" to properly use the word component and property correctly and carefully.
Issue is closed with this resolution.
Glen: Should be possible to annotate any endpoint (such as an EPR) with wsdlx:{interface,binding} not just a URI. Spec restricts to being able to annotate a URI.
Umit: The spec should not imply that this is the only case these attrs should be utilized; can be used anywhere.
Proposal: take the 2nd option and soften the spec to allow these to be used anywhere.
Umit: will we explicitly refer to an EPR here?
All: Yes we will refer to it. Stop being anally retentive about it.
Issue closed with the above plan.
Umit: we're ahead of the schedule and therefore we should go ahead and start drinking.
Jumping ahead to tomorrow afternoon
Jonathan: Proposal is to offer a shortened component designators, but notes that it doesn't work because we allow different symbol spaces in the same TNS.
DaveO: If people adopt some constraints then component designators can be simpler.
<Arthur> Dan wants: http://www.w3.org/2005/08/sparql-protocol-query#SparqlQuery
<Arthur> We have: http://www.w3.org/2005/08/sparql-protocol-query#wsdl.interface(SparqlQuery)
Jonathan: Go for it- if the context can constrain the scope to a world where restricted names occur.
Several people note that the sample that was indicated in the issue is inconsistent.
Arthur: The proposal's attempt at installing the ID constraint doesn't work for WSDL because WSDL spans multiple documents.
Sanjiva: Proposes to close the issue with no action.
JOnathan: clarifying: proposal is to shortcut the component designators to make it easier for the simple case.
Jonathan: Keeping the designators and doing this will cause problems because it conflicts (the proposed designator is a valid XPointer and our syntax extends that.
DaveO: The proposal appears to be creating a default ID attribute ... for certain cases.
<Roberto> q*
Arthur: there are 2 scenarios for the xpointer. Case 1: component designator case xpointer does not apply. In this case its doable to say use the bare name as a shortcut for the case when top level components are unique.
Case 2: for the case when the media type is present then its not possible to do this because it conflicts with XPointer.
Rebecca: Does this affect last call?
Jonathan: We don't use component designators internally .. and since this doesn't go on the wire it probably will not demand another LC.
Bijan: Alternate proposals that may satisfy this issue: Looking at it from an RDF view- having trailing parans is a problem.
... the real issue is to pack ugliness to the prefix and keep the last part clean. That would help the situatoin.
Are parans illegal in RDF?
Bijan: No. But it doesn't support the URI abbreviation syntax used in specs like SparQL.
DaveO: schema also went thru a similar model .. but if the convention of uniqueness can be done then it can be supported for those cases when it works.
Amy: proposal: if these are going to cause problems then can we move the component designatators in a separate deliverable?
Jonathan: we voted to do that but didn't do it before because there was no public WD of the RDF mapping. We can move it to the RDF doc.
Hugo: pulling it out would require going back to LC.
DaveO: two options: change the spec or reject the comment saying "doesn't work for WSDL"
Jonathan: Notes that these are not the only identifiers that can be used for WSDL2 components .. others are welcome to define their own.
Bijan: appreciates the power and cleanliness of what we have
<sanjiva> Sanjiva: +1
<dorchard> I'll point out for the record that we do not have any web arch documents explaining why parenthesis are "bad" in URIs.
<charlton> +1 - we should close, no action
Resolution: close with no action
ACTION: DaveO to draft a response and send to the WG [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action02]
Sanjiva: it appears that we can do this already
Postpone until tomorrow for clarification.
<Zakim> hugo, you wanted to say that they are right
<hugo> OK, I am confused: SPARQL uses application/x-www-form-urlencoded and we defined application/x-www-urlencoded; what's the difference?
Hugo: we define --form-- too; see http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#_http_binding_default_rules
<hugo> oh, I see; it's a typo in the SPARQL spec talking about ours then
ACTION: Editors to examine use of "Note that" and review those to make sure those are not interpreted as non-normative notes. [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action03]
Comment 1 of Issue 344: accepted
Comment 2 of Issue 344: see action item 3
Comment 3 of Issue 344: closewith no action
Arthur recommends noting that the same paragraph has been clarified in response to another issue.
Comment 4 of Issue 344: proposed refactoring closed with no action.
Comment 5 of Issue 344:
Discussing the scope of {style} .. is it required to be understood
Jonathan: if the style attribute is not understood by a consumer, there's no need to do anything about it
Arthur: Style documents how the messages were defined and one is welcome to ignore them
Umit: RPC style defines some constraints on the schema
Arthur: If u understood the style u can determine whether the messages conform to the style. But you don't need to understand the style at all to process the messages.
.. Individual styles are like extensions and hence a validator should treat them that way.
.. The comment is about having two or more styles: then there can be a conflict.
... The solution is to say that the combination SHOULD be consistent.
Glen: Even if there's only one style, the spec must be very clear that the {style} stuff is optional from the point of view of the consumer.
Jonathan: We seem to be in agreement that we should clone the F&P composition note pointed to by Arthur should be copied to the style stuff.
Tom: Style is an assertion but it must be adhered to be a valid document.
Glen: But just like any other extension element, this is an optional extension.
.. this becomes a problem IFF one defines style as a required extension.
Sanjiva: We should note that styles are an optional extension.
Optional extensions are ignorable by the client already.
Umit: Wants to make sure that if the tool does understand a style URI then it MUST fault if the style is not followed.
Arthur: In the case of the reported probem, the document is indeed invalid because its not following the rules.
Jonathan: proposal to fix :
.. 1. remove "it is an error"
.. 2. copy the stuff from section 6: if things compose u might get yourself screwed
.. 3. styles are optional extensions
ACTION: Arthur to draft above as a proposal to be able to close this issue [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action04]
<alewis> I have a problem with the initial sentences/paragraphs of part two, sections 4.2 and 4.3 (IRI style and multipart style). Both say that the styles apply to any MEP with an initial message. This is *weird*. What is an MEP without an initial message? Is such a thing possible?
Amy: questions the first sentence of section 4.2 of part2 .. the last 2 words seem to make the sentence are totally useless.
ACTION: editors to look at sections 4.2 & 4.3 of part2 and see whether the first setences (paragraphs) are no-ops. [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action05]
ACTION: editors to fix the first paragraph of section 4 .... does not make sense at all right now. [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action06]
Tom: Notes that there's an inconsistency in section 4.1.2 because the abstraction of signature stuff doesn't match with the syntax
Basically change all the (q,t)'s to (t,q)'s
Apparently its correct schema-wise but the schema's union stuff can be written in the other order to make it slightly easier for those of us who are not speaking schema in their sleep.
ACTION: Roberto to fix the schema in 4.1.2 accordingly. [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action07]
Comment 6 of 344: Closed with no action
Comment 6 of 344: Arthur to look at the text and clean it up
ACTION: Arthur to edit 2.7.1 and capitalize capitalize feature appropriately and define "feature" somewhere. [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action08]
Comment 7 of 344: Closed with no action (because of precedence for IRIs)
Comment 8 of 344: We agreed but we've dug this pit and we're going to lie in it. Its such a great pit that we can't see the light outside of it.
<charlton> This is splitting hairs
<charlton> I agree, this one is out of a Marx Brothers screenplay
Comment 9 of 344: Remove last sentence of paragraph 6 of section 2.9.1
Comment 10 of 344: Damn we've been sleeping for too long. Accepted.
Comment 11 of 344: leave it as is
Comment 12 of 344: close with no action, although it is possible some improvements may occur when Arthur adds test assertion markups.
ACTION: Arthur to look for simplification options for comment 12 of 344 [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action09]
Comment 13 of 344: {address} is optional because non-URI addresses are possible.
ACTION: Editors to add a setence saying {address} is optional because it could be defined by other means, such as an WS-A endpoint reference or maybe the scenario does not require an address. [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action10]
<Roberto> /me proposes: An interface component must define bindings for all the operation components and those within the fault reference component that contains the actual value of the property components of each interface fault component and those within its parent binding operation component within the interface component corresponding to the property element information items.
ACTION: Jonathan to point his out when it gets implemented [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action11]
<pauld> Scribe: pauld
<scribe> Chair: JMarsh
<Roberto> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/att-0046/wsdl-rdf.html__charset_ISO-8859-2
marsh: we have one readily available customer: DAWG WG / SPARQL
... in our charter as a Rec track deliverable, we need to make sure that level of interest still exists given that was some time ago
... plan: publish as a WD, get comments, not sure what CR testing would mean. Normally this could take a year to move to Rec
... this is fairly constrained and builds upon a stable foundation, could take less
... we could publish this as a Working Group Draft
... concerned about lack of resources / attention from the membership - we only have two members of the WG working on this
... open mike time
tom: we have to do this, no?
marsh: it's in our charter, which makes it difficult for someone else to pick this up
bijan: DAWG, for example, don't produce Rec track things
marsh: does this need Rec track to gain adoption, or is it more of a live document?
bijan: ontologies are typically stable, akin to a schema, and can be extended by others
marsh: unusual for a WG not to deliver a chartered item, less worried now I've actually seen a draft
... assume Jacek and Bijan want to deliver this within the WSD WG
tom: I'm OK so long as it's OK for the WG to deliver something few have time or ability to understand
roberto: what level of participation can we expect in the group?
bijan: it's a direct document, almost like another serialisation, so not too difficult to understand
marsh: plan is to keep this in the WG and move it forward to a Rec
kevin: Charter demands a Rec?
marsh: yes
... how far is this from Last Call?
Jacek and Bijan: 6 weeks seems realistic (but we have a F2F in 4, something to aim for)
Jacek: mapping still missing, plus some comments resulting from yesterday, e.g. the description element to be incorporated
marsh: wants to take a formal vote on moving to first Working Draft
... it's a Working Draft, so content make change, however it's the act of publication that's important
pauld: is this a point of no return?
marsh: no, it could wither on the vine
sanjiva: my feeling is this hasn't had enough WG pariticipation to be a Rec, it should be a note.
http://www.w3.org/2004/02/ws-desc-charter#deliverables
scribe: "A mapping to RDF of this language (W3C Recommendation)."
kevin: not comfortable to produce a Rec on this work
marsh: can work with the coordination WG to address that concern
kevin: if voting now to go to Rec, I'd vote no
pauld: what is your concern, not having full participation, taking the working group time, or the deliverable itself?
kevin: taking the working group's time
bijan: don't think this is heavyweight and shouldn't take too much of our time
sanjiva: my concern is this being published under the Working Group's name
roberto: what is the point of no return?
bijan: going to Rec is the point of no return
roberto: has there been a precident of something going to CR/PR and not making it to Rec?
marsh: xml packaging
amy: web services architecture?
roberto: we could get swamped by comments during Last Call
marsh: or get no comments!
... we could cross that bridge when we came to it
ACTION-1
marsh: this could flush out others in the community to gain help
bijan: schema working group had a similar requirement, which they ignored
tom: as chair can you go to the Director about this (paraphrased :-)
marsh: I'd prefer to get information now, rather than when we've done the work and are in PR
daveo: BEA has no problems with this devliverable, but don't want to expend effort and WG time on this
... question is how to time-box this and separate this from the main track of the WG
<charlton> +1: If we can break this out from the main track in such a fashion, it would satisfy the desire to address this mapping along with not impeding the main track
marsh: I can do that as Chair, splitting the group could make this go faster whilst demonstrating the interest or lack of in this
arthur: agrees with Sanjiva, can we publish this as a note today?
<uyalcina> i will say more on the queue, but +1 to Sanjiva, Arthur
marsh: still needs some work before being ready for that level of publication
bijan: this is lightweight, and there are other aspects of our specs which haven't had full Working Group attention
umit: my company is nervous about the timeline for WSDL 2.0, this could be a step too far
marsh: we can move forward (possibly to Last Call) without impacting to Working Group too much
bijan: will elicit further support, but would like to not close this down now
marsh: Director is aware of this problem, via Philippe
bijan: a note or submission could be less constraining than a Rec
tony: VOTE VOTE VOTE
Fomal Vote: Shall we move the Web Services Description in RDF document to first Working Draft?
Adobe: yes
IONA: abs
RW: yes
Sonic: abs
Sun: abs
University Maryland: yes
BT: yes
Canon: abs
Macromedia: abs
Oracle: abs
W3C: not present
DERI: yes
SAP: abs
TIBCO: yes
Microsoft: abs
BEA: abs
CA: abs
IBM: yes
marsh: no nos, several yes's and many abstains. So Working Group approval to publish as a Working Draft
operation stylesshould mandate content model
Glen: +1
tom: this in adjuncts, and only covers the styles we define. sounds good.
RESOLUTION: LC330 closed by accepting Jacek's proposal
<kendall> yeah, me neither
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC331
amy: can be empty, even if it's any?
sanjiva: this seems redundant
marsh: key part is "the payload"
amy: change it to "must be a single element"
umit: we have an empty marker
amy: if these are just guidelines, then let the MUST show up in the must be adhered to ..
arthur: whats the difference between the interface assertions and the binding assertions? does the text in the interface talk about payloads? is payload a binding construct?
amy: section 6.3 offers clarification for why we separate the default binding rules
tony: looks like a mirror of 5.3
roberto: seems like we already cover this in part1, part2 should just say follow part1 and stick it in the body
tom: lets tweak and move on, not rewrite blocks of text
amy: 5.3 and 6.3 should at least be more consitant with each other
sanjiva: for faults you have to have a fault action, there's no way to default that
umit: suggests rewording part1 section using MUST - helps those generating test cases
sanjiva: this section is perfectly testable. lets stop rehashing the spec in this detail
discussion spirals around MUSTs
arhur: we do need some MUSTs in the binding, not just the interface for testing against concrete messages grabbed off the wire
tom: lets change the MAY to a MUST as per Jacek's proposal and move on
sanjiva: the MUST be adhered to is sufficient at the top of the list
staw poll: resolution for LC331
option: jacek's proposal
vote: 9
on the phone 1
option: remove uppercase keywords from bullits
5
RESOLUTION: close LC331 by adopting Jacek's proposed text change
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC333
sanjiva: design point we don't do defaulting in the component model
amy: didn't know you could do interfaceless bindings :-)
<jjm> neither did I!
sanjiva: the component model is complete, regardless of what is defined in the document
glen: would be nice if the defaults were present in the component model
amy: but the defaults don't appear until you bind to an operation
... you want to change the component model at the last moment>?
glen: ok, there are work-rounds, and we could just leave this as an exercise for the reader
marsh: suggest we add these as extra properties to the component model, not change what's already there
glen: don't see that as a huge change
amy: concerned that this is going to be a substantive change
umit: drop with no action
seems like there is some confusion over how defaulting works with interfaceless bindings
marsh: lets leave this issue open while sanjiva and roberto investigate
<scribe> ACTION: Sanjiva and Roberto to investigate defaulting with interfaceless bindings [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action12]
<Marsh> I think I'll do the next chunk in this order: 337, 338, 245, 332, 323
<Marsh> fast and easy ones after lunch ;-)
<kendall> Thanks!
marsh: DAWG Issues, HTTP serialisation issues, 334 can wait until after lunch
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC337
fault serialisation
kendall: we don't have a known set of mime bindings, we want to allow any type to come back with a fault
<kendall> phone cutting out, FWIW :>
<kendall> i'm going to dial back in quickly
marsh: section 6.5.2 Relationship to WSDL Component Model
... doesn't think token includes wildcards
bijan: don't think Hugo's proposal helps. kendall's proposal is to make this optional, absence means any
kendall: making this optional, default meaning any would be fine
... for the output serialisation we would like an enumeration as well
amy: sounds like optional is simple and straightforward
bijan: doesn't help the enumeration case
... the work round for enumeration was hacky and would probably lead DAWG to not use WSDL at all
... optional does at least help us, though does mean we'd be underconstrained rather than overconstrained
... we'd prefer to be correctly constrained :-)
... this isn't just for faults
daveo: the alternative i suggested in the list was to write an operation for each media-type returned
<kendall> but that leads to an ugly blow up of the # of operations; roughly query forms * mime-types * 2 (post & get)
pauld: is this trying to descibe what's available for content negotiation?
<kendall> No
daveo: not exactly, it's what the server provides
... sounds like it is based on content negotiation
<kendall> If I understand (hear) DaveO's question, the server returns RDF/XML by default for CONSTRUCT & DESCRIBE queries
<kendall> I can't hear much, but I think I heard the q right.
<kendall> but if client wants another serialization type of an RDF graph for a DESCRIBE or CONSTRUCT, it can use con-neg to ask for N3 or N-Triples
<kendall> DAWG doesn't want it to look like Accept. We don't want there to be any priority implied.
<kendall> I.e., no q stuff. ;>
pauld: server presents possible types available and something in the message triggers the response, might not be the accept headers
<kendall> Sorry, we don't *need* that. I don't take a position, as a member of this group, on this issue generally.
<kendall> Correct.
<kendall> RDF/XML is teh default given DESCRIBE & ASK query forms
daveo: there is an implied priority as there is a default, followed by the available options
<kendall> application/sparql+xml is the return IMT given SELECT & ASK query forms
pauld: seems like a useful use-case and something we should be able to describe
<kendall> But, DaveO, that's the spec's default. We intend to allow particular implementations to set some other default. We have a postponed issue to write a domain-specific service description language, SADDLE, in RDF to express SPARQL constraints (inference type, RDF datasets, default output types, etc)
umit: there is a difference between this and the media-types in that it's the whole message that's being switched
marsh: */* seems nicer that optional, and then we move to text/* and then is it useful to describe character encodings? seems like a slippy slope
tom: don't think we'd wnat to unconstain input, no?
discussion of reusing media-types content negotiation description
<kendall> phone connection was fine till I actually needed it to work :>
anish: no 'accept:' and we disallow characters not available in XML
umit: not sure it will work all the time, this is only for the output?
amy: this is only in WSDL, not sent on the wire
umit: concerned we're desrcribing yet another content negotioation method
amy: thinks we are covered because we say the message MUST look like that ..
... looks like we could reuse / refer to the media types document
pauld: +1
marsh: we'd have to copy given it's a note and this is a normative reference
http://www.w3.org/TR/xml-media-types/#expectedContentTypes
daveo: can we work through the defaulting?
amy: no method of providing defaulting in the HTTP binding
anish: suggest an informative reference to the media-types work
amy: we should be comfortable given the working group effort that went into the note
<kendall> Thanks!
kendall: can we have the proposal in IRC?
<kendall> if it's too long, I'll just let Bijan speak for me :>
<alewis> proposal: copy the content of section 2.2 of the Describing Media Types for Binary Content note (a product of this WG) into part two, AND
<alewis> point the definition of whttp:inputSerialization, whttp:outputSerialization, and whttp:faultSerialization at that definition, AND
<alewis> check other references to these serialization properties to insure that they do not improperly restrict serialization to a single mime type.
<anish> Describing Media Types for Binary Content - http://www.w3.org/TR/xml-media-types/
<anish> + add a informative ref to the Note above
<jjm> What's the impact on moving forward to CR?
daveo: there is now a relationship between the schema type and the media type
amy: we should run this past Hugo given he's likely to be the editor
sanjiva: worries this will take us back into last call
marsh: optionality would be a similar impact given it loosens a constraint
sanjiva: we could add an option '*/*' as a compromise
<sanjiva> proposal:
sanjiva: this is a small bug, we could use '*/*' (or whatever) to indicate any media type and then use the media types spec to describe the contents of the message at the element level
<sanjiva> - allow inputserialization etc. to be fixed or the special string */*
<sanjiva> - if the schema has the expected mediaTypes annotation then */* can be further constrained
anish: the annotation is really intended to assist base64binary, isn't that a problem?
umit: seems like DAWG aren't likely to be using base64binary in all cases
<kliu> note section 2.2 of the media type doc says
<kliu> Users of this attribute information item are urged to avoid using wild cards (for example, "image/*") as it may lead to interoperability problems. If the set of expected media types is not known, the use of xmime:expectedContentTypes is NOT RECOMMENDED.
<kendall> we're probably not going to use it in *any* situation, AFAICT.
<kendall> If Amy's going to yell at me, I demand a better phone connection! :>
discussion of wildcard comments received to the media types discussion
<kendall> and, yes, this is all about me. -wink-
<kendall> my comfort level is high
<kendall> thanks
marsh: is this change going to take us back to last call?
... if so we could move the HTTP binding into a separate Rec track
<kendall> thanks, all
marsh: any adoptions to accepting Amy's proposal to LC337?
... none heard
RESOLUTION: close LC337 with Amy's proposal
<kendall> it's possible that LC345 is based on a misunderstanding...
<kendall> we want to be able to POST urlencoded in the body with no part of the In Message serialized in the URI...
<kendall> if we can do that, if someone will tell me how to spell it, I'd be grateful.
<kendall> sounds fine
<scribe> ACTION: Kendall to document reasoning behind raising LC345 [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action13]
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC332
sanjiva: HTTP binding only works on simple MEPs so you'd need an extension anyway
kevin: likes Jacek's proposal, but we're in a late stage
discussion of defaulting and multiple faults
marsh: for input and output this looks like an asthetic change, but for faults we'd be adding new functionality
sanjiva: looks like over functionality for HTTP
marsh: is the only difference between input, output and fault serialisation, the names? can we collapse them?
<GlenD> chad, new vote
<chad> new poll
<charlton> at the moment we have +2 for Trader Vic's
<GlenD> chad question: Where should we have dinner?
<GlenD> chad, question: Where should we have dinner?
<GlenD> chad, option 1 : Trader Vic's
<GlenD> chad, option 2 : NOLA
<charlton> vote: 1
marsh: we applaud Jacek's excellent design, but it's a little late ..
<GlenD> vote: 1
RESOLUTION: close LC332 with no action
vote: 1
<GlenD> chad, what is the question?
<RebeccaB> chad, options?
<sanjiva> how about doing dinner in San Francisco Fisherman's Wharf? I have to go up there so I'd love a late dinner there ..
<Arthur> vote: 2
<anish> vote: 3
<anish> vote: 2
<uyalcina> vote: 1
<uyalcina> chad: 1
<charlton> chad, count
<chad> Question: Where should we have dinner?
<chad> Option 1: Trader Vic's (4)
<chad> Option 2: NOLA (2)
<chad> 6 voters: anish (2) , Arthur (2) , charlton (1) , GlenD (1) , pauld (1) , uyalcina (1)
<chad> Round 1: Count of first place rankings.
<chad> Candidate 1 is elected.
<chad> Winner is option 1 - Trader Vic's
<TomJ> vote: 1
<charlton> chad, count
<chad> Question: Where should we have dinner?
<chad> Option 1: Trader Vic's (5)
<chad> Option 2: NOLA (2)
<chad> 7 voters: anish (2) , Arthur (2) , charlton (1) , GlenD (1) , pauld (1) , TomJ (1) , uyalcina (1)
<chad> Round 1: Count of first place rankings.
<chad> Candidate 1 is elected.
<chad> Winner is option 1 - Trader Vic's
<charlton> straits (http://www.straitsrestaurants.com/)
<charlton> chad, please list the options
<charlton> chad, please list the options?
<charlton> chad, what is the question
<charlton> chad, options
<charlton> chad, option 3: Straits
<charlton> chad, option 4: Zibbibo's
<charlton> info for the restaurants:
<charlton> trader vics (www.tradervicspaloalto.com)
<charlton> nola (www.nolas.com)
<charlton> straits (www.straitsrestaurant.com)
<uyalcina> vote: 3
<RebeccaB> vote: 3
<charlton> zibbibo's (http://www.restaurantlulu.com/)
<Marsh> vote: straits
<Marsh> vote: 3
<charlton> vote: 3, 1, 2
<GlenD> vote: 4, 3
vote: 3, 1, 2
chad, option 5: in and out burger
<charlton> chad, who has voted
<TomJ> vote: 5,1,3
<charlton> chad, who has voted?
<charlton> chad, count
<charlton> so far we had 5 votes for Straits in first place
<TomJ> in-and-out!!!
<charlton> ping
<TomJ> Scribe: TomJ
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC323
reviewing Hugo's mail on the issue
proposal is to move text to the primer and add some clarification along with it
Jonathan: anyone object to hugo's proposal?
no objections
RESOLUTION: LC323- accept hugo's proposal per his email on 23-Sept-05
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0043.html
Confusion about how imports work
Arthurs response may have clarified the issue
(response via Email)
Paul's response enumerated the possibilities well also.
Jonathan: Is there something we can improve in the primer, since this reader was confused.
Amy: maybe we can try to clarify XML Schema, but not a fan of doing that.
Kevin: We have a whole section in the primer about this
Paul: WS-I precludes using xs:import in the <types> section of WSDL 1.1
Sanjiva: WS-I made a mistake in this case.
<charlton> The Basic Profile use of xs:import breaks the XSD rules
sanjiva: We should put something more in the primer
Kevin: We already have something, but is it enough?
Examination of section 2.3.2 in the primer.
Sanjiva: Add a note at the bottom of table that points out that WSDL 2.0 is different that common 1.1 usage patterns. Also adding an example
tomj: can't we use paul's example and have a much more info?
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0022.html
discussion of the examples. Adding a negative example to text would help.
proposal: add a note at the bottom of the table, add a negative example.
Jonathan: any objections?
None
<scribe> ACTION: Kevin to add the text to the primer. [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action14]
s/text/text and examples for import/include/
Bijan: Kendal seems to have a misunderstanding because of the example in section 6.8.1.2.2 (in editors copy)
... all the message can go in to the body, nothing in the URL
<scribe> ACTION: Editors fix "Case Elements NOT cited" in 6.8.1.2 header to be "Case of elements NOT cited" [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action15]
examination of the relevant section (6.8.1) to determine if you can have the entire message in the body and nothing in the IRI
Sanjiva: We should just specify that for GET, everything by default goes in the URI, for POST everything goes in the body
Amy: This would change the default encoding
... very concerned that the HTTP binding is not ready to go to CR yet.
Bijan: enumerates some assumptions that Kendal had on reading the text, some of which are wrong
Jonathan: What do we want to do for this issue?
... 1. maybe make the default behavior dependant on the GET/POST operation: Get on URI, POST in body
... 2. explore the slash notation and its usage around that.
<pauld> pauld: unhelpfully points out that the looser we are in the HTTP binding, the easier it is for someone else to write an extension to constrian it
Much discussion about how the binding currently works and how to fix it...
A few problems with section 6.8 (editors draft) indicates that some major bug fixing is needed
Roberto: Can we split the HTTP binding away fro mthe rest of the spec?
Amy: dependancy in the SOAP binding to the HTTP binding.
Jonathan: Take a break and we can work on the binding over the break?
... Do one more issue then break
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC334
Jonathan: In addressing we changed it for localization reasons
Sanjiva: looks like we need to code to map faults to status codes, but reason seems not useful
<charlton> How was it changed in WS-Addr?
<charlton> Anish: Note that in SOAP 1.2, error 500 is not required
discussion about HTTP status and reason codes
Amy: if we include reason, we have to provide i18n (list of strings, etc)
<anish> sanjiva, look at table 17 at http://www.w3.org/TR/2003/REC-soap12-part2-20030624/ for SOAP 1.2 http status code
tomj: propose to accept the issue and remove the reason code.
<anish> and table 20 as well
Jonathan: Any objections?
RESOLUTION: LC334 - remove the reason code from the HTTP fault binding.
<charlton> http://www.w3.org/2002/ws/desc/5/lc-issues/#LC344
finishing up #13 - guidence for optional address
tomj: doesn't recall us making a decision on that, other say we were not going to provide anything
checking the minutes for whay happened yesterday
resolved that we were going to add text for #13
(reading the issue..)
RESOLUTION: accept suggested wording in #14
discussion of actual value vs. value
Roberto: Actual Value means (see section 1.4.4, glossary)
Arthur: The component model is not in XLM space
<Marsh> RESOLUTION: No change, "actual value" is about XML, the component model is in math space.
<Arthur> the values of properties in the component model are not XML values, actual or otherwise.
<Marsh> ... post-lexical processing.
<Arthur> the values have already been converted to "Math" space
<charlton> "The phrase actual value is used to refer to the member ot the value space of the simple type definition associated with an attribute information item that corresponds to its *normalized value*.
major geeking out on the term 'tuple'
<charlton> A tuple a finite sequence of objects, that is, a list of a limited number of objects
RESOLUTION: it is a tuple, closed with no action
<Marsh> WG feels that the pair is more "structured" than "ordered".
<sanjiva> additional info for #16: Tuple: http://en.wikipedia.org/wiki/Tuple, Ordered Pair: http://en.wikipedia.org/wiki/Ordered_pair
Arthur: Thinks that a table in section 2.19 might be worth while as QName resolution confuses many readers
tomj: proposes to close this with no action as section 2.19 is clear
Jonathan: Any objections?
Roberto: Can we just remove some descrption to make it clear?
discussion on QName resolution for various things (operations, interfaces, etc)
Amy: propose change: "property of the description component" to "property of the appropriate component"
Sanjiva: We must go and visit all the other places in the spec that talk about QName rsolution if we remove the reference to the definitions component
Three proposals:
1. close with no action
2. enumerate the deescription components (i.e look for interfaces in the interface component)
3. Remove section 2.19 and inline the info where we have links in the document
Arthur: when reading the spec, it's nice you have info local. We put this info in other places, why not on the top level things?
<alewis> chad, new poll
<chad> new poll
<alewis> chad, option 0: close with no action
<alewis> chad, option 1: enumerate properties of description component instead of the existing example of one property
<Marsh> Chad, option 1: enumerate 4 examples
<Marsh> Chad, option 2: distribute 2.19 throughout the spec
<Marsh> chad, options?
vote: 0,1,2
<pauld> vote: 0
<Allen> vote: 0, 1
<TonyR> vote 0, 1
<Arthur> vote: 2, 1
<hugo> vote: 1, 0, 2
<Marsh> vote: Roberto: 2, 1
<bijan> vote:0, 1,2
<alewis> vote: 1,0
<sanjiva> vote: 0, 1
<Marsh> vote: Glen: 0,1
<RebeccaB> vote: 0,1,2
<charlton> vote: 0, 1, 2
<Marsh> vote: 1,0,2
<kliu> vote: 0,1
<Marsh> chad, count
<chad> Question: unknown
<chad> Option 0: close with no action (9)
<chad> Option 1: enumerate 4 examples (3)
<chad> Option 2: distribute 2.19 throughout the spec (2)
<chad> 14 voters: alewis (1, 0) , Allen (0, 1) , Arthur (2, 1) , bijan (0, 1, 2) , charlton (0, 1, 2) , Glen (0, 1) , hugo (1, 0, 2) , kliu (0, 1) , Marsh (1, 0, 2) , pauld (0) , RebeccaB (0, 1, 2) , Roberto (2, 1) , sanjiva (0, 1) , TomJ (0, 1, 2)
<anish> vote: 0, 1, 2
<chad> Round 1: Count of first place rankings.
<chad> Candidate 0 is elected.
<chad> Winner is option 0 - close with no action
Jonathan: any objection? None
RESOLUTION: close LC344 - #17 with no action. The spec is clear
Break for 15 minutes
<Arthur> It's worth recalling the story of the very famous mathematician G.H. Hardy, who in a lecture said about some detail in a proof: �This is obvious.� After a pause, he went on: �Hmm, is it really obvious?? After another pause he left the room to consider the point, returning 20 minutes later with the verdict: �Yes, I was right, it is obvious.�
<uyalcina> Reminds me, "nice work if you can get it"
back from the break
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC344
Amy: propose we close with no action
Group believes that english text is clearer that using terms like transitive closure, etc.
RESOLUTION: Close with no action
A reading of the spec, the location attribute must be dereferenceable: "It is an error if the IRI indicated by location does not resolve to a WSDL 2.0 document."
REVOLVED: close with no action because location does have to be dereferenceable
RESOLUTION: Thank you for the comment.
LC344 - all items addressed
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC346
RESOLUTION: All typos assigned to the editors
<scribe> ACTION: Editors to fix typos raised in LC346 [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action16]
Item #2 in LC346
<scribe> ACTION: Arthur to reword references in 5.3 to avoid confusing WS-addressing endpoint references [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action17]
RESOLUTION: Editors to fix endpoint references
RESOLUTION: LC346 - #3, add WS-A reference
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC345
Sanjiva presents work done over the break
GET/DELETE - everything in the URI, must follow the URI style
POST/PUT - none thru everything can go in to the URI
This is satus-quo with fixes.
For POST/PUT, none has no impact on the style, all with IRI style is possible.
For form-encoded POST/PUT, you must use IRI style
For mulit-part-form POST/PUT all data can be in the body
<pauld> proposal on whiteboard: http://www.flickr.com/photos/psd/47255269/
with any operation style
The two bugs are: 1. POST - no way to get no parameters in the URI
2. Incorrectly specify how to put data in the body, we say text/xml instead of form-encoded
in the form-encoded content-type case.
Alan: do we care about a GET with no parameters?
working on syntax changes to support a fix for bug 1 - how to get no paramters in the URI
Fix for bug #2: instead of serializing XML, serialize as form-encoded, and only serialize parameters you haven't already put in the URI
RESOLUTION: apply this fix as a partial resolution for LC345
<scribe> ACTION: Editors to fix this part of the HTTP binding for form-encoded [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action18]
Proposed Syntax for bug #1: whttp:includeUncited="true/false"
true - uncited elements turned into paramters
false - uncited elements NOT turned in to parameters.
Discussion on how to default the value of whttp:includeUncited
GET/DELETE - default value is true; POST/PUT default value is false (uncited elements go in body)
GET/DELETE - default value is true (uncited element are thrown away);
POST/PUT default value is false (uncited elements go in body)
Jonathan: Who can write this up in to the spec?
Hugo and Amy express some interest, but are horrified by the current state of the spec.
Sanjiva: Important: if the XML is IRI style compatible, you can put some of it in to the IRI, but the whole XML must go in the body
We also want to relax the restiction that the XML has to conform to the IRI style, in the case that POST/PUT application/xml or multipart style and you have no parameters (no cited elements)
<scribe> ACTION: Hugo will write up the resolutions for review [recorded in http://www.w3.org/2005/09/27-ws-desc-minutes.html#action19]
<pauld> latest version of the diagram: http://www.flickr.com/photos/psd/47263522
roberto: can we relax the style so that only paramters that will be in the IRI have to conform?
Discussion of this idea.
tomj: that would be cool
tomj: what do we have left
Jonathan: 3 issues, including the HTTP items just discussed (and are awaiting proposals on), then we are done
i18n said they would be 3 weeks late, want to handle those issues
<uyalcina> ah
Jonathan: Editors have lots of work coming out of the meeting. Good to get it done fast.
Thanks to Amy and TIBCO for hosting.
Adjourned