W3C XML Protocol Working Group teleconference, 25 September 2002

1. Roll call

Present 23/20 Excused Regrets Absent Name abbreviations used in minutes:

2. Agenda review, and AOB


no new items of business

3. Approval of 11 and 18 Sept telcon minutes


no objections to approving 11th sept minutes
no objections to approving 18th sept minutes

4. Review action items


>2002/07/31: Asir 
>Draft email to xmlp-comments to close issue 338 with status quo 

pending

>2002/08/01: Gudge 
>Research infoset properties of header and body children, and suggest
>appropriate changes 

done

>2002/09/04: Editors 
>Send e-mail to xmlp-comments closing all editorial issues. It's OK to 'batch' these up. Editorial discretion on how much we put into each response. 

pending

>2002/09/04: DavidF 
>Contact implementers regarding updates to their implementation of table 2 of the implementation table 

pending

>2002/09/04: DavidF 
>Organize (or outsource) an implementer telcon for finding out how the implementation table can be tested 

pending

>2002/09/04: Editors 
>Incorporate ref #8 (Resolution of issue 221 amended by Noah's proposal) with the understanding that XXXX is a sender fault 

pending

>2002/09/11: DavidF 
>Provide a plan for possible f2f meetings between Mid Oct through Mid Nov (Dates mentioned on the call) and call for hosts to volunteer 

pending

>2002/09/11: AF Editors 
>Prepare last call WD EOB Monday for final check next week. 

done

>2002/09/11: Editors 
>Make state, role, and failure properties URIs 

dependence on 305

>2002/09/18: DavidF, Carine, Yves 
>Take AF doc to last call ASAP. 

done

>2002/09/18: Asir 
>Send request of clarification of details on closing issue 338 

done

>2002/09/18: Marc 
>Provide text for issue related to table 17 based on the
>"http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0167.html"
>but with the text pulled out to before the table as it may apply to
>other status codes as well.  

done

>2002/09/18: Editors 
>Incorporate changes wrt 292 resolution http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0175.html 

done

>2002/09/18: Marc 
>Send closing text for issue 292 

done

>2002/09/18: Noah & Henrik 
>Try drafting a clearer justification to Joseph Reagle on issue 250. 

done, henrik to send

>2002/09/18: Jacek 
>Send detailed email to xmlp-comment and commentator, 185 and 297. (a draft may be sent to Wg for review) 

pending - draft sent, henrik comments, updated draft to be sent

>2002/09/18: Henrik 
>Talk to Gudge about recovering the text for issue 353 as per "http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0062.html" 

done

>2002/09/18: Jacek 
>Write a proposal for new attribute for issue 231 and send it to member list 

done

5. Status reports

-- Primer
Nilo: nothing to report.

-- Spec
editors:  much of the closing texts (for xmlp-comments) has been sent out, no other items to report

-- Attachment Feature doc
df: published as a Last Call WD yesterday, comments will go to the existing LC issue list

-- LC Issue List
carine: it is up to date

-- Implementation tracking [2]
df: nothing to report

-- Media type draft, IANA application
df: nothing to report

-- Planning Oct/Nov f2f
df: we have a potential host for meeting (Sonic). There are 13 attendees so far, and the room holds 20.
df asks whether anyone else plans to attend the f2f ... the number of attendees increases to 18...
There is no objection expressed to holding the f2f meeting at Sonic in Bedford, MA.

6. LC Issues [3]

-- Discussion of pushback to any issues we have closed
no pushback identified

-- Part 2, Table 17 discrepancy
Per last week's telcon, Marc proposed new text [5], and there seems to be
agreement on this with a few small changes [6]. Any objection to accepting
the proposal in [5] plus the changes in [6]?

no objections to accepting this as resolution to the issue
Herve logged this originally - Carine will find the thread and log it as an issue in the LC issues list

Data Model Issues
-- 302, data model edges orignating and not terminating
How should we resolve the situation described in [8]?

jk - we discussed this on the previous call and decided to use the original proposal text rather than the amended text that nopw appears in the Editor's copy of the spec. So I thought we were waiting to see the original text again.
df: notes that the resolution of editorial issue 353 affects the text under consideration for issue 302
jk: the clarification clarified 302, the other proposal by Martin Gudgin is not satisfactory
hfn: the only things that have been changed in the editor's copy are those that are colored (uri pasted into irc); I don't understand what you think has changed..
jk: editors draft when gudge sent mail was different than what it is now in bullet 4. It used to talk about inbound only and outbound only edges, which
it doesn't do in the current draft
df: in summary then - there was intermediate text form that had been seen by enough persons to be agreed upon and now that text is not in the editors copy of the spec
jk: yes
df: there is a precedence for resolving these issues - 353 was editorial and 302 is substantive, so 302 take precendence
hfn: but the text is not agreed upon until now
df: there is enough memory of the existence of a tranistory text that we should recover that text and use it as the resolution for 302
hfn: where is it?
nm: can we use CVS to find the text?
df: presumably it was a draft checked in.
hfn: then we can get back to it 
df: reopen action to henrik to recover that transitory text
noah: for discussion?
df: need to see the text again, we can't make a decision until we see it
nm: ..to contribute to a discussion rather than adopt?
df: yes
df: for next week's telcon, we expect to see a variety of text, specifically: one will be the recovered text, a second will be the text that is available today, and a third will be gudge's other proposal. We will make a decision when we've seen all three texts.
df: if hfn finds text, then he will post it

-- 231, what is the difference between a struct and an array in the edge case?
During last week's telcon, we resolved this issue by agreeing to introduce
a new attribute whose name and values were to be decided. At the WG's
request, Jacek created new text [26] describing the attribute, and
initiating a discussion of the name and values. Some changes were suggested
and accepted by Jacek to his initial proposal [23].
We do need to choose a name and its values:
Name choices--  valueType,  content,  node,  nodeType   (all in enc:namespace)
Value choices--  simple/struct/array,  simple/struct/array/false, terminal/struct/array

df: first thing we need to do is to lay out the arguments so that we are clear on what it is that this attr can or cannot do; for example, can its value be defaulted, how does such a mechanism work, etc
df: ray, please summarize what you would like to be able to do with schema and this attribute
rw: currently when using schemas we have to go to great lengths if something is an attribute. It seems that adding this as a default we could have one unified way that we could find out if it was an array or whatever. Without that I can't see the value of adding another point on all the conditions we have to check for
df: what is your proposal?
rw: how it would work with schema is not the intent - the thing objected to in the proposal is that the value of the infoset property was true which would prevent a schema or dtd from providing the information about whether is is a struct or whatever. I propose we don't specify that the value of specified has to be true
df: so a schema could provde the attribute's default value?
rw: yes
nm: this issue is not captured properly in the agenda - take out the mention of 'false' in the value choices - clarify the proposal. I don't agree with ray's proposal but I don't think the status quo is very far from what he wants. Part 1 states that none of the values could be provided by a schema and they must be in the message - the question is what Part 1 should. Historically, schemas are optional to avoid scripting problems and dependence on particular schema languages. There is a precedent however - we say in non-normative references that 'can build a better decoded graph if you use schema'. So it is possible to construct two graphs from a soap message - one where you don't use schema (normative), and one uses schema to add more information (non-normative). If you take the spec as it stands, then if you validate the document, and add the default, then you can modify your graph. Nothing precludes this.
df: response from ray?
rw: A lot of the noah's premises are not true - that was done in email. What I'm proposing does not put constraints on processing model. Very often, the so called normative graph is useless because you cannot tell significant pieces of information what you are decoding
df: not everyone finds it useless
rw: it depends on the messages - we haven't done the work at the encoding level. I consider script access is a poor implementation when it does not use schema.Oour callers from mozilla etc certainly has all this.
df: the point being made is that nothing prevents you from using a schema to validate the encoding
rw: yes, but this new attr is somehow not relevent if it came from a schema. If the processing model did modify the infoset it should be recognised as a general approach rather than a prioprietary mechanism
marc: my understand of the attribute's purpose was to help with self-description of an encoded graph in the absence of a schema. If you can default in schema and omit from message, then you lose the point of the attribute because the information is not there.
rw: ..
mh: why?
rw: the use case in which the thing is not self-described is important to a lot of people. It's difficult to detect if the incoming things is an array.
mh: [puzzled]
jk: ray is concerned that if you have a schema then you know the structure, and the attribute is redundant in that case. Keeping it having the infoset property set to true doesn't effect the schema and clarifies our intent
df: is there a negative interaction depending upon whether the attr is set or not?
rw: I don't understand statement
df: if the attr is set, the schema can still validate that piece of xml but in addition it will be able to provide other information about the types and strycture of the xml and there's no negative consequence that the value is true.
rw: the point is that the schema cannot easily determine if it is an array
jk: if we allow this attr in schema, we will extend schema to understand soap encoding. A schema currently tells you the structure without the use of the attribute.  If we agree on that then it is true that the attr doesn't affect schema.
rw: there are (??) proprietary and tricky techniques for this and if you are using DTDs etc it wont work
nm: proposal: ray doesn't want people to invent this themselves (agreed) - I think this is a fairly large design change. We have a precendent in appendix C  - suggest we amend this to say that if default or fixed values are provided to encode attributes then their values may be used to appropriately augment the graph. This will cater for what ray wants and will stick with decisions we've already made.
rw: this proposal comes closer than anything I've heard and will solve the itemYype issue. I'm willing to pursue this direction although I am unsure of the exact wording.
df: is there any other input?
mh: I am concerned about the  wording.
nm: It was not meant to be exact ... it only introduces an attribute in the enc: namespace
df: we just need assurance that this is a reasonable direction 
rw: I believe it is 
df: we need somebody to volunteer to produce text....
nm: I'll take it 
no objections!!
discussion to follow on dist-app

df: can we decide what are the choices of values for this attribute and what is the attr's name?
general: yes
df: what are the choices for the values
jk: simple/struct/array and terminal/struct/array
df: there was some discussion that the use of the word 'terminal' may be confusing. Hence it looks like the former set of values are preferable, is there discussion?
no discussion
df: Is there any objection to specifying the set of values to be simple, struct, and array?
no objection
df: it is decided, simple, struct, and array are the permitted values for this attribute

df: are there preferences for the name of the attribute?
jk: because we allow the value 'simple', I think that valueType is the most appropriate attr name because the word 'simple' is only used in the spec in the
valueType (??)
rw: has anyone considered anything that doesn't involve 'type',  like 'class'?
mh: this may be reasonable because we are 'above' the type level?
df: to avoid naming black hole on the phone, we'll take the naming discussion to email

df: is there anything anything else to consider on this issue?
jk: which list should we use for the naming discussion and who will send the first posting?
df: dist-app
action: jk to initiate discussions wrt name of attribute

RPC Issues
-- 306, is use of Appendix A optional?
Do we indeed have consensus that Appendix B (nee A) is referenced from the RPC section and its usage is "SHOULD" [13].

hfn: the initial proposal was from me, and I'm fine with the Appendix being referenced from the RPC section - I have no deep feeling on this.
no discussion
df: is there any objection to closing this issue with the proposal?
no objections
df: the issue is closed with the proposal
action: df to send mail to xmlp-comments and originator

-- 298, RPC array representation unnecessary
Some support has been expressed for the issue [24].

df: Jacek, please outline the rationale for this issue
jk: in soap1.1 we had named attributes and this had been the model all the time until john ibbotson came up with a proposal to add array represntation of rpc. In current implementations there are named attributes (they are soap1.1). The LC WD asked for feedback as to whether this should be kept or removed. Systinet's position is that it should be removed, and we note that wsdl does not support it yet.
hfn: same feedback from microsoft
rw: I am fine with proposal as long as people are clear as to what it means. I thought that the reference over-trivialized the issue. There is a fundamental difference here that struct cannot be accessed by a positional index, yet many implementations access parametrs by position rather than by name. So, we want to make sure that people realize that we are throwing something away
df: what goes away?
jk: remove from the RPC all mention of the array representation, a small change
no further discussion
df: are there any objections to closing the issue by removing all mention of array representations?
no objections
df: the issue is so closed

action: jk - send mail to xmlp-comments
action: editors confirm with jk to identify wording

-- 299, RPC return value accessor is too complex
Martin Gudgin proposes to close the issue by taking no action [25]. Does the WG agree?

rw: I was partly involved in the creation of that mechanism, and my preference was not to have the return mechanism at all, but needed something to prevent it from interfering with the schema. I can't see why a return value accessor is actually required, and if people want to get rid of it that's ok with me
jk: I agree with ray
df: what would be the impact to the spec?
jk: if we decided to remove this mechanism, the issue the impact is minimal in the text but it might be viewed as a big change
hfn: this is indeed a concern. It will break implementations that already exist, and we need to evaluate the impact on interop work.
jk: agree with ray, but not reply to gudge, because that's ok (??)
rw: yeah
df: if it was earlier, would we have pushed this change more strongly? I am think I am hearing to go ahead with Gudges suggestion, and acknowledge there is a big risk in making such a change.
hfn: agree
jk: yes
rw: users can avoid the mechanism if they don't like it
df: is there any objection to closing issue 299 without taking any action?
no objections
df: issue 299 is closed with status quo

action: mail to xmlp-comments and originator - Don Mullen

SOAP-supplied features
-- 304, no one-way MEP
Martin Gudgin has proposed that we close this issue by taking no action [29]. Does the WG agree?

df: yves has sent a proposal that we include a Request MEP. Jacek, why do you want this mep added?
jk: we mention soap abstract model that has oneway mep and it is mentioned elsewhere. It's been in the mindset all along, just not in the spec, and we should pursue this.
hfn: I am wondering whether this is a nice-to-have or whether it's fundamental to what we have?
jk: its always been thought that soap can be used for one-way messages. Wsdl has one-way operations (one of the basic things) so it is not really a nice-to-have.
mh: we would need to change the http binding to include a oneway mep
hfn: or provide another http binding
yl: oneway can only be in email and not in http which already has a response
mh: but this is in the other direction!
nm: I agree that the world will need oneway mep, but I am concerned that doing it right will have knock-on issues. Also, our meps become real when they are implemented in a binding, so if we do this, the mep should be reflected in a binding, and the only one we have is http which is inherently request response. So this is a bit bigger to do right than what I want to do to get out of last call. So on balance, I suggest leaving it out of this spec.
jk: I dont disagree .... I think ws-desc wg will ask us to this work 
df: why?
jk: wsd has oneway ops in the core...
df: for soap 1.2?
jk: don't know, it may be strange if those guys do it...
df: is there any objection to closing this issue by taking no action?
yl: it may be good to postpone so if we find time we can still get a proposal into the soap1.2 spec
df: this will be a major change, which will send us back before last call, and if we want to make it real we'll need a binding and that will make it a huge task.
yl: I don't think it is a big change
mh: people should be able to make their own bindings
nm: my point is that there is no point in putting the mep in the spec when there is no binding in the spec. This is too big a change to make at last call. We should say its structurally decoupled and it's just a policy matter of who does it (a oneway mep) later.
df: are there any objections to closing this issue by taking no action?
no objections
df: issue 304 is closed with the status quo

action: send msg to xmlp-comments and commentator - jk

-- 305, SOAP-Response MEP does not need sending+receiving states
Henrik has proposed a resolution [27] that has support although it will require fairly extensive changes to the HTTP binding section. Do we accept the proposal?

jk: the problem is that sending+receiving state implies that something is being sent there
hfn: this is a change in the state machine, mh says it will be editorially painful
mh: dave.orchard likes it
hfn: that makes me feel batter!
mh: we need to decouple the meps in the http binding, which means more text and tables
hfn: can we acheive the same thing by just putting in text to say that for the request response mep both those states are the same?
mh: maybe
df: sounds substantial - should we look at text before deciding?
hfn: editors take action item to come up with some ideas (additions to existing proposal) and see how we can achieve this. Question is whether this a good direction - I consider this to be mostly editorial really
df: ask the WG? 

action: hefn, mh: come up with one or more concrete proposals 

HTTP binding
-- 319, clarification that HTTP does define base URI
Henrik has proposed a resolution [28]. Do we accept this proposal?

hfn: in the binding framework we say that underlying protocol can define a base uri. HTTP does this, and so we should say so.
nm: I basically agree - we should make clear that our http binding uses as its base the base that http uses itself
hfn: that's fine

[at this point the minute-takers phone exploded and he was off line for about 40 seconds]

df: is there any objection to closing the issue with the proposal?
no objections
df: the issue is so closed

action: hfn to send msg to xmlp-comment

Envelope issues
-- 356, Allow unqualified elements as children of Body
After a lengthy discussion [9], there seems to be consensus on new wording. Is there any objection to accepting the proposed wording?

rw: is this a change to the status quo, and if so, what was broken?
hfn: we required that all elements in the body are namespace qualified. The comment came back saying there are lots of scenarios where no qnames.
rw: and they couldn't just wrap in an element?
mh: but question is why do they have to?
rw: ok
nm: I agree nothing breaks but...agree since the body interpretation has been loosened up...but...feel that the only way we keep things in order in this very loose world is by using namespaces. It just kind of makes the message a lot less self describing... 
...
nm: some day we might regret this (!)
hfn: it is true for any XML
dm: I agree with noah; it doesn't feel right, lots of people would be dispatching off the children of the body
hfn: yes, people should use namespaces - there's nothing in our spec which says anything breaks ns or no ns
mh: could put some wording in there to recommend using namespaces
hfn: there is some wording in there 'strongly recommend'
nm: it should say SHOULD
df: so I think we are asking for the MAY to become a SHOULD
hfn: from a compliance point of view this means conditional
[basic diagreement of what SHOULD means - resolved when RFC consulted]

straw poll: MAY+note vs SHOULD .... the SHOULDs have it.

proposal: close 356 using the text referenced in the agenda but changing the MAY to a SHOULD

further discussion

action: write the motivation of why there should be a SHOULD - noah

revisit this issue next week.

[meeting adjourned]