W3C XML Protocol Working Group teleconference, 19 March 2003

1. Roll call

Present 14/11 Excused Regrets Absent

2. Agenda review, and AOB

No new items

3. March 6-7 f2f minutes and March 12 telcon minutes will be up for

approval
Both sets of minutes approved without objection.

4. Review action items, see

[http://www.w3.org/2000/xp/Group/Admin/#pending]
n11n pub: still not published
 yves: recent feedback from Steve Bratt requesting status of commitment for
working group. It should be published beginning next week if OK with Chair.
 davidF: what commitments are in question?
 yves: whether group is expecting to work on this later or not
 yves will to send revised text to member mailing list

W3C staff: we can keep PR namespace through Recommendation if there are no
changes to the spec

davidF: draft email to WSD WG with respect to WSD WG dropping 'use' attr,
propose to send jacek's modified version
No objection.

5. Status reports

-- Part 0
davidF: no report from Nilo recently, does anyone know anything? (No reply)

-- Part 1
-- Part 2
davidF: editors waiting for f2f minutes to double check, these are now in
hand
martinG: everything is done, checked all looks fine.
davidF: I believe that the ed copies of parts 1 and 2 are now effectively
the texts for PR?
martinG: yes
marcH: we just need to strip out redlining & change the namespace
jean-jacquesM : do we have to remove the changelog for PR?
davidF: yes
marcH: last-minute tidy up then ready
davidF: should we collectively decide that both docs are now 'more frozen'
than the normal editor copy?
martinG: what do you mean?
davidF: we should set a very high bar for changes
martinG: yes
davidF: i.e. modulo truly significant information, and implementation
evidence, there will be no changes
davidF: does that make sense?
martinG: editors are not planning to do anything to those documents!
noahM: if editors get urge to fix something, they will send a query to the
mailing list before doing anything
marcH: "i am committed to following such a process" :)
davidF: any objection?
None.
davidF: so let it be recorded that the editors commit to make no change to
specs without first formally consulting the working group
jacekK: new versions? link isn't there
martinG: editors copies haven't moved for a long time
noahM: link to editors copy goes to cvs, if you reference them in an email
they may be pointing to different texts
marcH: ignore the 06LC URI...
jacekK: so the last change on the second line of part 1 is feb 22nd,
correct?
martinG: last change is 8 march
jacekK: looks like the HTML has not been updated
noahM: we would need to have HTML pick up changes from f2f
noahM: looking for permission?
davidF: any objections to updating HTML?
None.
davidF: please update the HTML

-- Test Collection
anish sent regrets for the meeting, hence no status report
davidF: someone ping Nilo and Anish to gain precise status of these docs
marcH: I can ping Anish
davidF: please do so by end of this week
davidF: and someone to ping Nilo please
jean-jacquesM: will do

-- Registration of "application/soap+xml" media type, see
http://www.w3.org/2002/06/registering-mediatype.html
yvesL: I didn't talk to Mark Baker, I will do so this week

-- n11n publication
already heard about this

-- IPR
yvesL: no change, no new issues.

6. CR progress and issues,

http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html
-- CR implementation report, see summary table at
http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html#features

-- Status of nodeType implementation plans

davidF: there was a SOAP implementer's telcon this morning
davidF: status - impl page has 10 'features' that are pending
davidF: of those 10, 3 are actually complete, the summary table just needs
to be updated
davidF: assuming the implementers can twiddle test harnesses, should have 4
of remaining 7 done next week
davidF: there is a call next tuesday to ratify
davidF: 3 outstanding out of a total of 49, i.e. 94% done
davidF: will go through one more pass of the table to ensure that the
traces match up with the features so that the
evidence is as advertised. I expect this process will turn up at least one
feature fow which we will need another trace
davidF: In detail, the incomplete features are:
davidF: feature #2 : support of various soap roles
davidF: we have one trace for this which covers most of the roles,
davidF: between the #5 implementation and the whitemesa implementation,
davidF: we need another trace between another pairing of implementations
davidF: we ran out of time on the implementer's call and did not discuss
davidF: I request anyone on the current call who has been involved in the
implementations
davidF: to go back to their developers and see if they can come up with
davidF: traces to come up with feature #2

davidF: feature #77.2 : error feature
davidF: I think we can obtain a trace of the appropriate error msg back for
davidF: the missing id part of the feature. We plan to resolve this feature
with a single client,
davidF: the normal criteria is 2 different pairs of source and target
davidF: but what we are really testing in this feature is the behaviour of
endpoint, so we will relax
davidF: strict criteria on this one - hand-code some messages
davidF: and send to different targets
davidF: the untyped part of this feature is really hard to get a test for
because the
davidF: servers themselves have redundant mechanisms for typing
davidF: the arguments of operations, so even if client sends untyped
davidF: arguments, then the servers can use other mechanisms. So we have no
davidF: plan to finish testing of #77.2 - and it looks like no progress
davidF: to get traces for untyped. Again, I urge members to go back to
davidF: their developers to see if this can be made to happen.
jacekK: this fault code is close to that of the node type attribute
jacekK: in most toolkits the information that these carry is in
jacekK: the wsdl, but they may need to be in restricted environs,
jacekK: so consider this faultcode similarly to nodeType

davidF: feature #3 : nodeType
davidF: gudge (martinG) will give overview of responses to developers
martinG: responses so far
 whitemesa: done
 tibco, microsoft : not done, not looking for it
 sys : not done
 glen/mark/paul: no response
 bea: not done, and will not be done for months

davidF: net of it then, as best we can tell, there is a single
implementation
davidF: of nodeType, others are not implementing it. We need to consider
how to
davidF: handle this.
davidF: There appear to be two ways: (i) drop nodeType from spec, (ii)
leave in spec.
davidF: Regarding (ii) we say it is part of soap encoding which is optional
and go to
davidF: W3C with the evidence provided by Whitemesa to say it is possible
to implement it,
markJ: likes (ii)
martinG: get rid of it!
jacekK: keep it
davidF: if we left it in for PR, and explain the situation to W3C, then
even if we
davidF: are held to the criteria, the worst case maybe they would
davidF: come back and say remove it. The feature is an independent item,
and
davidF: going from PR to REC it would be easily excised.
martinG: that's fine - will need to change namespace URI
noahM: I'm a little baffled, it doesn't seem to me that the spec does
noahM: anything with this except accept certain values and reject the rest
noahM: you don't do interop testing on hints
martinG: testing is meant to flag an error if the hint doesn't make sense
martinG: with the data
noahM: trying to get to the point of there may be limits to what people
noahM: have to do to get thru an interop test
noahM: for example echo test is beyond the bounds of the rec's mandate
martinG: text does not say anything about if it is wrong
noahM: some degree of checking implied - impls don't blow up if it is there
markJ: does this come under 'new information'?
markJ: seems like a minor fix to make it more complete
martinG: it is a minor fix to take it out!
davidF: not real demand for this, whitemesa said "oh i can put that in"
noahM: should we go back to the history when soap1.1 had something similar
noahM: and now our philosphy is you can look at an encoded soap message
noahM: and know what graph is and that's why its there
jacekK: in one approach to layering a soap stack, not having that there was
jacekK: difficult in some edge cases
noahM: I think the nearer you get to using scripting languages, the more
people will care.
noahM: example soap system that can process dynamically
noahM: like jacekK, I would like to keep nodeType
noahM: perhaps if we remind the impl community to just accept the attribute
and interop
noahM: would still be ok
davidF: problem with interop testing - implementors have bug list, project
davidF: schedules, it may seem like a small thing to us, but their
schedules are fixed etc
jacekK: prefer to keep it if we can get it past W3C and timbl!
davidF: what does the W3C staff think?
yvesL: we can keep it if we clarify it is not implemented due to time
constraints etc
yl: rather than arguing about why we have it etc
davidF: I suggest we make no final decision right now
davidF: the WG should consider this at next weeks telcon, should concretely
davidF: decide go, no-go. At next week's telcon there should be a very
small number of features
davidF: that are not completed.

davidF: has there been any pushback on any issues closed?
None reported.

7. Attachments (11.40 + 50)

-- Status report on a description of the single-infoset approach
davidF: Microsoft and BEA said they will produce a single infoset approach
document for this friday
davidF: can we get a status on this?
martinG: I believe we are on track to publish something on friday
davidO: I confirm this
davidF: where will the document be published?
davidO: on our individual websites and a link on dist-app
davidF: can you tell us what will be in that document: a model, an
implementation?
martinG: primarily a description of an implementation of the model, but
does talk about
martinG: the model
noahM: it seems to me that it is important that we come out of the process
with
noahM: a good separation of the model and the wire format
martinG: the action from the f2f was for a concrete example of that model,
that's
martinG: what the document does.

-- Status report on XMLP WG scope vis a vis single-infoset approach
davidF: I have been in communication with the W3C about this, we'll hear a
summary from yvesL
yvesL: we have discussed scope and technical concerns about unserializable
infosets
yvesL: most people thinks that it falls in the scope of the working group
yvesL: we have still to discuss some technical details, but the friday
document will
yvesL: help us with some of those issues
yvesL: it will be especially helpful if we can see document before 1500
hours UTC on Friday
martinG: that is not going to happen! Rather, it will be sometime around
lunchtime Redmond time

-- At last week's telcon, we decided to try making progress on the more
general set of attachment requirements while awaiting more information
about the single-infoset approach to attachments. For this effort, we will
start with Mark Jones's categorisation of the requirements at
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Mar/0027.html.

davidF: markJ will take us through the requirements as listed
davidF: general question for each one - does the WG agree that the
requirement should be part of the attachments reqs we take on board?
davidF: we may want to shuffle some of the requirements into different
buckets
davidF: we should figure out which ones we agree to and postpone discussion
on the others
noahM: clarification: we never did much in the way of requirements for a
model,
noahM: are these requirements for the implementation of a model?
davidF: I understood from the AFTF there was a mix of both
noahM: AFTF had requirements for implementation. Comments were made there
that some
noahM: of these were requirements for a model, need to decide what's what
davidF: so, as we go through these requirements, we will initially make
determination on whether it is a model requirement
davidF: but we will do them all
noahM: and there may be some work to do later

markJ: the section 2 requirements are relatively free of the binding model
markJ: R17 - "whatever proposed should work with soap http binding"
noahM: this relates to both the model and the implementation
davidF: so, should we label it model and implementation?
noahM: yes, then move on for now
markJ: is the model the same as the abstract description?
noahM: yes
markJ: potentially a parallel set of requirements at the model level
davidF: so, is it agreed that R17 is a rwquirments on both model and
implementations, and we accept it?
No dissent.
davidF: so it is agreed

markJ: next set of Rs are talking about representations, these are
markJ: relatively independent of any processing model
markJ: R1 - carry multiple data parts
markJ: this may need wordsmithing to be a model requirement
noahM: in general these requirements are only polished in the context of
implementation requirements
noahM: I suggest we spot the ones that have crept in that are more from the
model context
noahM: and revisit them later
davidF: OK, it is agreed that these are all implementation requirements by
default unless we specifically identify them otherwise
davidF: agreed that R1 is a requirement

markJ: R2 - carry arbitrary data, binary, xml, etc
davidF: agreed that R2 is a requirement

markJ: R3 - efficient implementation of representation of the parts
(parsing etc)
davidF: no great discussion, any problem?
davidF: agreed that R3 is a requirement

markJ: R4 - representation should use space-efficient representation
martinG: it is difficult to quantify "space-efficient" but I think it is
reasonable
davidF: agreed that R1 is a requirement

markJ: R5 - not overly burdensome to add remove parts by intermediary
davidF: agreed that R5 is a requirement

markJ: R13 - must provide support for arbitrarily large parts
noahM: I agreed in AFTF and agree with general spirit - if this is model,
then
noahM: fine, but this is the implementation, you can imagine impls that
noahM: have no limit and some that just go very very big
markJ: should it be "should" instead of "must"?
noahM: well, you want to handle very very large stuff, but not arbitrarily
large,
noahM: so maybe a 64 bit length field or something like that
davidF: do you propose to change 'arbitrarily large' to 'very large'?
marcH: what does 'very' mean? we need to set a limit...
noahM: not sure understand tradeoff...not sure how to get it into the reqs
noahM: right now.
markJ: we can say arbitrarily, but implementations will limit themselves
jacekK: when i wrote the requirement i imagined potentially not ending
parts, so
jacekK: they can go on for ever. The specification should provide support
for this,
jacekK: some stacks may not be able to handle it, thats the implementation
davidO: I observe that specifying sizes for things regularly comes up
during requirements gathering
davidO: it always seems to be problematic - like the wording "arbitrary"
because
davidO: it gives the notion 'very large' but doesn't try to nail it down
davidF: it seems that 'arbitrarily' implies there is no limit. In choosing
between
davidF: "arbitrary" and "very large", 'arbitrary' means any size, is that
the
davidF: distinction we want to make?
marcH: arbitrarily finite?
davidF: that would work for me
noahM: respectfully disagree with jacekK - what if you are doing two of
these
noahM: parts then they have to be interleaved - this doesn't make the 80/20
cut
noahM: my intuition is to keep this a little simple and not go for
unbounded
noahM: in model ???? yes, but not in concrete implementation requirements
noahM: what i could live with is implementation should not necessarily
noahM: preclude the sending of very long parts
davidF: I am writing down the choices, and we'll take a quick, non-binding,
straw poll
markJ: I could live with noah's last suggestion
davidF: 4 choices:
 arbitrarily large -> very large; 0 votes
 arbitrarily large -> arbitrarily finite; 2 votes
 status quo; 2 votes
 not unnecessarily preclude transmission of very large...; 3 votes
davidF: this is inconclusive, please take the discussion to email, and
we'll start with this topic next week

davidF: are there any other attachment proposals/issues?
None