Minutes of 7th XMLP WG F2F Meeting, 2002
Hosted by W3C in Cannes-Mandelieu, France.
Aggregate Roll
Present
Cisco, Raj Nair (rp)
Intel, Highland Mountain (r)
Macromedia, Glen Daniels (r)
Mitre, Paul Denning (r)
Sun Microsystems, Chris Ferris (r)
Canon, Herve Ruellan
Canon, Jean-Jacques Moreau
DaimlerChrysler R. & Tech, Mario Jeckle (p)
DevelopMentor, Martin Gudgin
EDF (Electricite de France), Olivier Boudeville
Hewlett Packard, Stuart Williams
IBM, Noah Mendelsohn
IBM, David Fallside
IBM, John Ibbotson
Idokorro Mobile (Planetfred), Mark Baker
Intalio, Bob Lojek (p)
IONA Technologies, Oisin Hurley (p)
Matsushita Electric, Ryuji Inoue
Microsoft Corporation, Henrik Nielsen
Netscape, Ray Whitmer
Oracle, Anish Karmarkar
Rogue Wave, Murali Janakiraman
SAP AG, Volker Wiechers
SAP AG, Gerd Hoelzing (p)
Software AG, Dietmar Gaertner
Sun Microsystems, Marc Hadley
Systinet (IDOOX), Jacek Kopecky
W3C, Yves Lafon
WebMethods, Camilo Arbelaez
WebMethods, Asir Vedamuthu (p)
Excused
DaimlerChrysler R. & Tech, Andreas Riegg
Developmentor, Aaron Skonnard
EDF (Electricite de France), Philippe Bedu
IONA Technologies, Eric Newcomer
Microsoft Corporation, Paul Cotton
Mitre, Marwan Sabbouh
Netscape, Vidur Apparao
Rogue Wave, Patrick Thompson
Systinet (IDOOX), Miroslav Simek
W3C, Hugo Haas
Regrets
Active Data Exchange, Richard Martin
AT&T, Mark Jones
Cisco, Krishna Sankar
Compaq, Yin-Leng Husband
Intel, Brad Lund
Interwoven, Mark Hale
Macromedia, Simeon Simeonov
Philips Research, Yasser alSafadi
Philips Research, Amr Yassin
Software AG, Michael Champion
Tibco, Don Mullen
Unisys, Lynne Thompson
Zolera, Rich Salz
Absent
Active Data Exchange, Shane Sesta
AT&T, Michah Lerner
BEA Systems, David Orchard
Compaq, Kevin Perkins
Ericsson, Nilo Mitra
Fujitsu Limited, Kazunori Iwasa
Fujitsu Limited, Masahiko Narita
Interwoven, Ron Daniel
Martsoft, Jin Yu
Tibco, Frank DeRose
Unisys, Nick Smilonich
(r) = remote attend
(p) = partial attend
Morning, February 25
Noah Mendelsohn scribe
Action items being logged to IRC
Current Events
Pending action items
2001/12/05: HenrikN & DavidF
*DF Reports RDF has not responded but is here in Cannes
*UML: Mario not here
Follow up on links to requirements from external WGs by monday noon EST.
2002/02/06: DavidO, davidF
Figure out the interactions between XMLE and XMLP
*DO is not here (9am)
2002/02/13: HenrikN & NoahM & Chris
Wordsmith the proposal for dealing with issue 137
* Henrik: see also issue 176. Discussion for most of this is started.
There have been proposals to solve all the issues.. Will try to do during
these two days.
2002/02/20: Gudge
Cull dist-app and xmlp-comments for new issues for F2F
*Comments done, 250 out of 900 to go on distapp
2002/02/20: StuartW
Write back comment on the comments on issue 133 closure (Cc: Paul Prescod)
*Stuart: we've announced WG is done with this. Also, TAG may be
considering this.
2002/02/20: DavidF and compliance editors
Follow up off-line regarding moving SOAP 1.1 tests forward to SOAP 1.2
*Anish: Oisin is right person to give update on the document. DF Action
Done
2002/02/20: Gudge
Take issue 142
*Done
2002/02/20: Oisin
Take issue 36
*Not done
2002/02/20: JohnI
Take issue 51
*Done
2002/02/20: Amir
Take issue 41
*Not Done
2002/02/20: PaulD
Take issue 54
*Not Done
2002/02/20: GlenD
Take issue 56
*Not Done
2002/02/20: StuartW
Take issue 67
*Done
2002/02/20: MarcH
Take issue 154
*Done
2002/02/20: Jean-Jacques
Takes issue 61
*Pending for now
2002/02/20: DonM
Take issue 82
*Pending
2002/02/20: Henrik
Take issue 17
*Done
2002/02/20: Gudge
Take issue 110
*Pending
2002/02/20: Yves
Make 175 a dupe of 137
*Done
2002/02/20: Jacek
Draft resolution text for issue 59, TBD during f2f
*Done
2002/02/20: Gudge & Henrik
Produce text for issue 181 by EOB Friday
*Done
2002/02/20: StuartW
Rewrite the proposal wrt cardinality on issue 182
*Done (but discussion ongoing)
=======End of Pending Action Discussion==========
Discussion of Publication
=========================
Part 1:
-------
Editors report it's in fair shape.
DF not completely clean, but perhaps close.
Noah: I did a complete readthrough. Don't think it's up to other W3C
specs. Some substantive, but nothing that will blow open the design.
Henrik: Risk of reopenning the whole design. Going to Last Call signals
going into different mode of operation...dealing with issues.
Long discussion of where we stand on the spec. Seems to be feeling that
we're close, but not entirely polished. Henrik points out that new issue
resolutions will surely change the text. Noah: it's not as clean as
other W3C specs, rest of WG should review more carefully. DF: there will
surely be time for review after issue text is integrated.
DF: let's talk about specifics in 5.1
Ednote in section 5.1 framework: Henrik TBTF has proposal, but needs WG
approval. See proposed resolution of issue 178. DF: OK, we'll take up
w/178.
Ednote in 6.4: (security) Henrik: the text in
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0048.html covers
it (see meeting page)
Part 2:
-------
Mark Hadley: some sections in part 2 have no content. DF: all covered
by issues.
Ednote in section 3: Gudge says mostly OK, but 3.5.2.2 is not rewtitten.
Net: that ednote is resolved.
Ednote in 3.1.2: Gudge: we already say what type of ID is. Remove the
sentence in question and the ednote. Agreed w/o dissent.
Both Ednote in 3.3: Regarding deletion of examples. Noah notes that there
is also substantive explanation of use of derived types. Hadley:
partially overlaps rule 3 in sectiond set on serializations. Noah: yes,
but that's a very obscure way to introduce that derived types can be used.
Proposal: Editors have discretion to get rid of examples, but must give
clear explanantion of use of derived. types.
Edinote 3.5 (first): Editors already have discretion to remove examples.
Ednote 3.5.1: Gudge: there's lots of duplication from serialization
rules. Noah: why not make the serialization list short, and refer to
comprehensive explanations in the 3.5.x sections (as opposed to putting
everything in the serialization list). General agreement. Latitude to
the editors.
Ednote section 4:Gudge: how can I rewrite 4 in terms of infoset, when
it's not in terms of XML in the first place? Agreed: nothing need be
done. RPC is in terms of the data model.
First ednote in 6: Editors can deal with this.
Ednote in 6.1: Stuart W. We need to explain why it's "single" req/resp.
Noah: why not just drop "single" in the name. Henrik; while we're at
it, why is it labeled "Transport" MEP. Noah: he's right, that shouldn't
be there. Action: drop the "transport". Agreed: Drop "single" from the
name of the MEP and then no explanation needed.
Ednote in 6.1.3: Henrik: we don't have to say this pattern is
abstract...they all are! Agreed: editors to rework.
30 minute break.
===============================================
Continuing with ednotes
Ednote: 6.1.3 (2nd): leave to editors
Ednote: 6.1.3 (2nd): leave to editors
Ednote: 6.1.3 (3rd): TBTF
Ednotes: 6.1.5 and 6.1.6 TBTF to resolve
Ednote 7.3: leave to editors
Ednote 7.4.1.1(1st): leave to editors
Ednote 7.4.1.1(2nd): leave to editors
Ednote 7.4.1.1.1: TBTF
Ednote 7.4.1.1.2(both): leave to editors
Ednote 7.4.1.2 (both): TBTF
Ednote 7.4.1.2.1 (first): Create a new issue for this. ACTION: Stuart
Ednote 7.4.1.2.1 (2nd): leave to editors
Ednote 7.4.1.3: Tentatively on ediors plate. See issues 137, 176, and
especially watch for workgroup resolution of ednote in section 5.1.
Ednote 7.5.2: Delete section 7.5.2 Agreed without dissent.
Examples in B: Resolution: target them to illustrate A. a simple
envelope to go in part 1 B. examples of encoding C. Http binding.
Noah points out envelopes are infosets. Examples should say so.
Noah also points out that the examples currently use <?xml version= /> Is
that part of our abstract envelope. Gudge: version is now in the
infoset. Noah: do we use it in the definition of Envelope. Resolution:
Yves to open an issue to cover our use of infoset for the envelope, and
particularly the status of version. Examples to be made conformant.
Primer Review
=============
Ednote of 4.2: Several responsdents. This is not critical. Noah:
clarify term serialization vs. encoding. Stuart Williams: I think it
means encoding. DF: What about RDF/XMI examples. Ray Whitmer prefers
simple examples of other uses (not sure I got Ray's comment right.) Action
(Mark Hadley): ping Nilo to clarify what he's proposing to do.
Ednote section 5 Mark Hadley is writing a conference paper outlining
differences between SOAP 1.1 and 1.2. Volunteered the contents of his
work for the primer. Nilo proposes moving this discussion to a separate
note. DF: I think we should leave it in our spec, somewhere between parts
0, 1, and 2. Proposed resolution: keep it informal and keep it in the
primer. Agreed without dissent. We'll tell Nilo it stays in the primer.
Ednote at end of 5.1: resolution: not now for last call. Submissions
welcome from others over time. Agreed w/o dissent.
Ednote section 5.2: WG agrees with note. Delete the section.
DF: anything else on the primer. Noah and a few others. It's overall
very good, but needs a bit of review to make sure that for example the
overview doesn't scare off novices (it talks about Infosets.) Marcel Jemio
offers to help with a review.
Schemas Review
==============
Gudge (editor): believe they are OK and up to spec level.
DF: they are to be normative, will publish along with parts 1 & 2.
SOAP Binding to Email
=====================
DF: We had previously discussed publishing this as a note. Is it ready.
John Ibbotson: there are a few ednotes and loose ends.
Henrik: we've been busy. May need more review.
Stuart W: may need to keep it in sync w/ main document
ACTION(Jacek Kopecky): write letter of intent for email binding to
distApp. WG to review before it goes out. Due Friday.
Abstract Model Review
=====================
Agreed not critical path.
Discussion of what to signal to the world.
John Ibbotson: why not say it was influential in developing what we have.
Noah: agreed, we can say our spec deals much more carefully with
abstractions than it did.
ACTION: (Chair) will investigate possibilities for disposition. Will
include last call and long term proposal or options.
Test Collection Review
======================
Anish: Test collection document is in XML format. Not sent to WG yet.
Some sections not covered. Oisin may have update. MS has proposed
updates. Merge needed. Soapbuilders tests apply to 1.1. Many do apply,
however. Could tune them up, and include rather than referring to them.
Jacek: they are testing interop, feature by feature, and bug by bug. They
are not prepared as conformance test. Needs more than simple tuneup.
Ray: I would worry if we were signalling that the subset is what we're
testing. DF: what do they need? Jacek: selection...not clear if any
useful...they're quite narrow. Henrik: when can this be ready. Anish:
as a guess, two weeks. Anish to show revised document.
DF: will it be a WD?
General agreement to make it non-normative.
Requirements and Use Cases
==========================
John Ibbotson: I've been adding some pieces. DF: will you finish it?
JI: yes, if needed for publication, but I'm not getting lots of comments.
Some debate about the role of the usage scenarios.
Resolution on use cases: Jacek and David Fallside to evaluate the usage
scenarios.
Requirements
============
DF: we openned issue for each requirement. Does that cover it?
Concensus.
Noah: the glossary and the layering model no longer fit.
Some discussion. Noted that if it's ever needed for the AM, it was in the
Req doc working draft.
Agreement to drop the glossary and layering model from the requirements
doc. Action to editors.
Usage scenarios stay in requirements doc.
Afternoon, February 25
Stuart Williams scribe
14:20 CET
Issue 178:
----------
DF: Introduces with context of its relationship with ednote in part 1
Section 5.1. Current Proposal is at
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0244.html. David
requests a recap from Henrik.
HFN: TBTF has been discussing the scope of feature expression between the
binding and the SOAP envelope. This has been a 'big' discussion within the
TBTF and reported at various times to the WG. The idea is to look at
features express in the binding as having hop-by-hop scope and features
expressed in the envelope as having end-2-end scope. We leave open the
decision on how the node determines where to express a feature.
DF: Invites Noah to surface his editorial amendment.
HFN: Section 5.1 has now been elevated to a section of its own. It seemed to
be useful to call it out because we have increased scope than just a
binding.
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0252.html
NRM: 2nd part of amendment is in the current editors draft.
DF: Any objection to closing 178 with current resolution with Noah's
friendly amendment.
No disent recorded. Issue 178 is closed with the amended proposal.
ACTION: Herve to write resolution text and send to xmlp-comments
14:30 CET
Issue 179:
----------
DF: References
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0187.html
Marc: Original issue was that the binding framework mandates that all
bindings MUST support a one-way MEP.
NRM: Suggested amendment in References
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0194.html to cover
a concern that a binding could be defined that supported no MEP's.
HFN: Just a clarification... is the set of MEPs supported by a binding open
ended.
NRM: We defined a fairly formal notion of MEPs that have a spec. You can
then use that pattern in many ways to compose more complex sequences.
CF: I think this went a little further than where Noah's amendment takes
ups. I think we moved on to the word enable rather than support.
NRM: I'm ok with a change in wording, but I don't make a distinction between
enable and support. For example the RR MEP is very specific.
Glen: ... local discussion in Boston... don't think that it is sufficient to
say that if you can just move messsages then you can support all MEPs.
CF: I don't think it's very useful if you can't create some arbitrary MEPs.
GD: Emphasises the that you can enable more patterns by using the MEPs
supported by the binding,
HFN:...
NRM: We seem to be getting hung up on the term MEP. There are lots of things
that will feel like MEPs to users, but they are not the same things as the
pretty formal notion of MEPs that we have defined.
Marc: ditto to Noah....
DF: Any objection to closing 179 with the resolution plus Noah's amendment.
More discussion of enable and support ref
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0214.html
Marc: These are orthogonal issues.
HFN: Would not like folks to read this as requiring that folks define
DF: Amended proposal per 0194 mail with a further tweat to change "support"
to "enable".
Issue 179 is so closed.
ACTION: Volker to handle resolution text.
Issue 103:
----------
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0277.html
HFN: This is a reaction to the description of SOAP as being a fundementally
1-way model. With the binding framework this is basically editorial clean up
to say that "SOAP provides a distributed processing model, initial sender,
intermediaries and ultimate recipients".
Marc: Question about the word 'normally' wrt to qualifying the ultimate
recipient? Can we remove that?
Some discussion of error cases, dynamic routing...
HFN: Normally was an amendment introduced by the TBTF.
DF: Any dissent on so closing Issue 103?
CF: Just a couple of gnits...
a) phrase ultimate SOAP receiver and ultimate recipient.
b) clarification in distinguishing between 'an' and 'the' ultimate
SOAP recipient.
DF: So make the language consistent between the two paragraphs... (yes).
CF: Yes
DF: Reiterates on license granted to editors to massage spec. text to folks
joining by phone.
No disent recorded on closure of 103.
Action; John Ibbotson to send resolution text to xmlp-comments.
14:55 CET
Issue 33:
--------
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0273.html
Glen: These were the motherhood and apple pie reqs. This one was about
modularity. At the top we have all the mechanism of extension headers, mU
etc and at the bottom we have all the binding framework stuff which is all
pretty flexible.
DF: Any objections on closing 33?
No disent.
ACTION: Glen to send resolution text to XMLP comments.
15:00 CET
Issues 50 & 57
--------------
HMM: Issue 50 pretty much addressed by the creation of an email binding
(requirement to support multiple bindings).
Issue 57 also addressed by established by the email binding and with
reference to text in the binding framework.
DF: Looks like we need a little more text in the spec to address 57.
HMM: Yes...
Discussion HMM/CF on
DF: Propose to close Issue 50 per email on agenda (0276.html).
No disent recorded.
ACTION: HMM to send resolution text on i50 to xmlp comments
ACTION: HMM to prepare resolution proposal for i57 by tomorrow.
Issue 44:
---------
Glen: Issue raised by Vidur comming from requirements. Concern about
request/request response correlation over bindings that don't directlty
support RR. Resolution references the creation of the binding framework,
features and message exchange patterns.
DF: Is this sufficent to close i44.
Glen: I'm a little worried.... I'm fine with closing the issue, but I would
like for us to have provided a header based implementation.
NRM:... so a way to do this might be to define request/response for a UDP
binding. I don't think this is broken.
DF: No disent i44 closed as proposed by Glen.
ACTION: Glen to post resolution to XMLP-comments.
15:10: CET
Ed Note on security text:
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0048.html
DF: Security text written by Chris and Henrik...
CF: Henrik and I drafted security considerations sections for parts 1 and 2.
Three aspects a) Generic SOAP; b) Binding Framework; and c) HTTP binding.
Basically says that SOAP does not provide any security; provides caveats on
trust levels wrt to sources and sinks of messages; for HTTP binding we
leverage off of the security considerations of the HTTP spec.
DF: Discussion?
Mark Baker: I had some comments that don't seem to have made it into the
proposed resolution.
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0075.html
Concern is about tunnelling in that it 'violates' the constraints assumed by
the application protocol.
HFN: Do we have an agreed notion of tunnelling?
MB: Don't think this is easy to communicate.
NRM: When writing a spec. there is an artful line to be drawn between
elaborating the dangers of misusing the underlying protocols.
I would be tempted to resolve this along similar to resolution of issue 133
- placing the responsibility to do the right thing on the developer/user.
CF: Recaps on the narrative for the HTTP binding which itself references the
HTTP spec.
MB: Main concern is that the most common usage of SOAP is tunnelling and
somebody has to call out the dangers associated with that.
HFN: There is some commentary about using SOAP with other application
protocols bound to their default ports.
MB: This isn't HTTP specific at all. It is generic for any application
protocol (ie. SOAP tunnelling over xxx).
NRM: Problem that I have is that the resolution to this is that we
discourage you from abusing the transports you're bound too. It's easy to
take a purist architectural rules... but there are also some very useful
things that folks are already doing. I don't think we want to say 'don't do
this...'
MB: I'm agreeing with Noah, don't want to say "don't do this"... want to
say... "be aware of what you are doing".
CF: I think that is taken care of in what we have.
HFN: This a proposal... Mark Nottingham took an action to write Part 1
Section 6.3 which discusses application protocols on their default ports.
So proposal is to move section 6.3 as a subsection of 6.4 (security
considerations).
DF: I was going to make a slightly different proposal - to accept the HFN/CF
proposal is, to see it in context and the concern (MB's) may not be so
great.
DF: So proposal is to accept current proposal and to move 6.3 into 6.4. The
onus is on Mark Baker to review and propose any further amendments.
No Dissent:
ACTION: Mark Baker to review.
[Not a numbered issue so no resolution text to post]
15:30 CET Break:
16:15 CET Resume:
ETF Issues:
Issue 177:
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0089.html
HFN: Apparent conflict in part 2 over default values, null and nil. Current
text discusses default values only. Other question is what is the meaning of
an absent accessor... default, null, nil? Proposal is to interpretation of
missing accessor as NUL.
HFN confers with JK.
JK: as originator issue accepts resolution.
RayW: Question on parial arrays... which are now gone.
DF: Objections to closure?
No dissent.
ACTION: JK to send resolution to xmpl-comment.
16:15 CET
Issue: 113
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0231.html
HFN: Issues is about respresentation of a void result. Proposal is that if
the result accessor is absent then resolution to 177.
SKW: Long thread on rpc:result... is it related?
JK: No that's a different issue.
DF: Polls for closure.
No disent
ACTION: Murali to send resolution text to xmlp-comments.
16:25 CET
Issue 16
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0231.html
DF: Proposal is that the previous two resolutions resolve Issue 16.
ACTION: Murali to combine with resolution of 113.
Issue 163:
http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0223.html
Gudge: Explains that there is a difference between XML 1.0 IDREFs and XML
Schema IDREFs
Asir: Two attributes id and ref. We rule out DTD and dependency on XML
Schema processing. Consider 3 options, use DTD, use Schema processing, or
specify that id is of type ID from XML Schema namespace along with
health-warning that these are not the same as XML 1.0 IDs and IDREF types
hence doesn't turn up in infoset, some issues with using DOM...
Discussion of XPATH/XPTR...
NRM: There are subtleties about using schema id's/idref's outside of the
context of schema validation. eg. constraint on uniqueness of ID's. How do
we establish the context within which id's are unique.
Gudge: ...yep I think that is an issue.
NRM: We publish a schema for the envelope, are we expecting folks to
validate envelope.... just we don't preclude schema validation we just don't
mandate it.
Gudge: So it's going to be very difficult to get the right behaviour without
requiring DTD validation or Schema validation.
NRM: We should explain what our spec means on the context of nout doing
schema processing/dtd processing.
RayW: I think the language here is wrong, to link the language to DOM.
Gudge/RayW discuss DOM implications.
NRM: The schema spec. has changed. Uniqueness on id has propagated to the
part 1 spec (structures) its not part of part (datatypes).
Marc: We have to be careful on how strongly we word the health warning.
DF: Your suggesting we should be more subtle about what id and idref are.
Are we saying that we have to define the uniqueness constraints in the
absense of schema processing.
DF: Asir... do you agree with that.
Asir: Yes.
DF: Group?
HFN: I'm a little concerned that we might not be the only group with this
problem. Maybe we could expose the problem in the plenary.
Gudge: When we made the decision to move to ID/IDREF we may not have been
conscious of this problem.
Jeff: We spent a long time talking about ID/IDREF... I don't want us to
revisit that unless we consciously decide to do that.
Marc: Can we point to schema for this.
Gudge: Not really because its in the piece on validation.
DF: Do we have an agreed direction, then we'll look at how we do this... ie.
do we have to create our own definition of uniqueness constraints on
ID/IDREF.
More discussion on what it says in XML Schema.
Gudge: Validation constraints all in part 1.
NRM: Chris (F) is right, part 2 does reference XML 1.0 IDs/IDREFs.
ACTION: Gudge to draft definition on IDs.
Procedural motion to extend to 17:30.
Late Afternoon, February 25
Jean-Jacques Moreau scribe.
DavidF: do we still keep issue 163?
Gudge: uniqueness issue not based on 163; completely new. Will be difficult to
track if we keep the same issue number.
Henrik: new issue?
Gudge: yes, will write up new issue.
DavidF: resolution to 163 will be?
Gudge: option (c), plus text for the new issue.
DavidF: Gudge has taken action to add new issue and provide resolution text.
Issue 167
---------
DavidF: Issue 167, from Asir.
Asir: About enc:arrayType and xsi:type, which have changed a lot. From an
earlier version of the spec, this attribute must contain type and dimensions
of the array. When type does not have a name, unable to compute a value for
enc:arrayType, which is problematic since this is a MUST; ibid for xsi:type,
although ok since this is a MAY.
Henrik: resolution is @@@
Gudge: so don't use anonymous type, if unable to refer to them!
Asir: proposal: change to MAY.
Gudge: @@@
Noah: agree with Gudge. Like Asir's wording, but issue is quite subtle. Need to
talk about what the graph model is. Asir says validation is not required, which
means xsi:type could be present, but if not refering to built-in types, no idea
what type this is, could be simple or complex, just know its name. Could try to
infer from content, but could be fooled, eg. a date represented as an integer.
Anonoums types can only be used for @@@
Gudge: for global elements also.
Noah: should'nt go there at all, or fill in that whole story.
David: serious proposal, health warning, would take us too far away?
Noah: important for the WG to make an informed decision. Against resolution for
subtle reasons, what anonymous types are. Maybe we need a bigger effort, an
option we could choose, to describe what the graph means when validating or not.
Asir: clarification: where does validation play a role?
Noah: could give you examples or where we couyd go. For types like integers,
people could built model on top of SOAP. Take xsi:type called H. Schema says
integers between 0 and 10. Could built framework so that graph gets annotated
with the real type. Not sure if want to go there; it may be better to do do less.
Jacek: in my opinion, and maybe Noah's, encoding is fraud. If want to make
encoding right, would have to start from scratch. Not in our charter, and
should not be so. Could either drop encoding altogether or close our eyes and
go with what we have currently. Not sure which option is best.
Stunned silence
Gudge: issue about generic type coming out soon, could do well with removing
encoding completely.
Laughs.
DavidF: options are silence or removal. [David summarizes over the phone for
Boston]
Noah: if drop encoding, also drop RPC. Little nervous that this has called
trouble on soap-builders.
Jacek: need proposal if to make an informed decision.
Noah: can we defer this issue, until we see some text?
Henrik: optional proposal for how to use section 5 (former numbering scheme):
we have reservations about this,
DavidF: @@@
Henrik: have to make choices. Many of the threads discussed have shown @@@ fair
game to say we are aware of these issues, but this has been usefull in certain
context, so despite issues it's why it's here.
JohnI: clarification: does health warning prevent people from implementing?
Henrik: have already done this for issue 17.
DavidF: further clarifiaction: to be conforming SOAP processor, should implement
all of part1?
Noah: if building something which is not intermediary, don't implement all of
part1! should not go there. Would take us a while to do this.
Henrik: separate issue.
DavidF: maybe do provide more explanation. Do we want to pursue this? Has been
suggested need piece of text. Is this what we want to do? Some small group of
people?
Gudge: Noah, do we w
David: defer issue until piece of text.
Gudge: will keep coming up; so need text.
Noah: @@@
DavidF: ok? we do have volunteers?
DavidF: ok, will defer 167 until tomorrow; we will then have a piece of text.
Issue 17
--------
DavidF: Henrik: outline?
Henrik: clarify the optionality of data model and encoding, and their
relationship. Proposal: intend to represent language data into XML, if needed;
but no need to use it, if, for example, the program's data is already in XML.
DavidF: discussion?
MarcH: Henrik's text does not take into account closure for issue 48.
DavidF: what's missing?
MarcH: RPC depends on data model and encoding. This is not captured in Henrik's
text.
DavidF: can we consider 17 in isolation?
No objection.
DavidF: 17 resolved by accepting proposed text. Someone to send to xmlp-comment?
Gerd, resolution text?
Gerd: ok.
DavidF: MarcH, issue 48?
MarcH: RPC specifically requires our encoding and data model; but issue 48 is
already closed.
DavidF: so?
MarcH: the resolution for 48 was saying it also solved 17; it did part of it,
we've just solved the remaining part.
Noah: @@@
DavidF: is this the text we need?
Noah: no, status quo.
Henrik: question of whether we write it or no.
MarcH: can't remember how we have made that decision.
Noah: reopen decision that RPC is based on encoding and data model?
Henrik: no, been solved already
Jacek: but not in spec.
Noah: what
Henrik: does not really depend on the encoding.
Noah: important that it depends on the data model, eg. WSDL would need to change
otherwise.
Henrik: we are agreing, but it is just that resolution to 48 says something
different.
DavidF: what is missing.
MarcH: [recaps]
Henrik: [approves]
RayW: sounds like RPC based on encoding in section 5. So if missing encoding,
would be technically wrong.
Henrik: RPC says modelling as struct.
Noah: there's little more. Encoding signal combined with data model signal. RPC
says must use an encoding that supports the data model. Way to signal that is
through the encodingStyle attribute. If makes encoding which does not have
structs, not suitable for RPC. So encodingStyle attribute can be used to refer
to valid or invalid encoding for RPC.
Henrik: is text for 48 right resolution?
MarcH: investigate, tonight, before overturn resolution?
Gudge: will dine on your own, ok?
DavidF: reasonnable.
DavidF: 17:30, adjourn, reconveine at 8:30 tomorrow, continuing with issues.
Thank you all! We did pretty well today.
Morning, February 26
data model is a graph of nodes. The terminals () have lexical values (characters)
and optional type names. The non terminals (compound types) have edges leaving
node, and type name, but no lexical value, since don't allow mixed content.
Encoding needs to say: if parent element has item type attribute (array), the
type name is whatever is specified in xsi:type; otherwise is un specified.
Moving away from where we are today: not saying anything about simple type.
Today, say of integer, value must map to xsd:integer, but can't say anything
more since don't mandate schema.
Noah: spec mandates recognize integers, but doesn't say anything more, ie what
you are supposed to do with it.
Gudge: clarifies the way spec works today. SOAP has no idea, unless there is
an xsi:type: assignment is done by application anyway. In an appendix, we
describe what happens if you do decide to validate against schema: a lot of the
type names get filled in. Also: @@@, which fills in the value space, which would
give us what...
Noah: ...ambiguity in 1.1: understand integers, but not what to do. Turn this
upside down: core, ability to have type names; can validate against schema, if
you want to; one possibly is XML schema simple types, ie integers, etc. Other
possibility is to use schema processor, which is what people used to do for
1.1 when using simple types.
Gudge: not requiring validation; just providing something people can use if
validating.
DavidF: clarificationl: can interpret xsi:type against schema.
Noah: just what schema spec says. Possibility to validate against minimal schema
(the one to which you have added nothing). What if wanted to make schema
language completely pluggable: proposal coming very close to this. In SOAP, no
possibility to define attributes when encoding: contents represented as elements.
Chosen one attribute: xsi:type, but value is out of the spec. Everything else
is just in an appendix: see W3C schema spec and validate if needed.
Jacek: current encoding says soap array must be
Gudge: need to do something. Don't require schema processor, so don't know what
this means.
Jacek: propose to remove requirement, and mandate arraySize.
Gudge: itemType optional.
Noah: if something carrays arraySize, it's an array, if @@@, structure, if
xsi:type.
Stuart: backtracking to if parent terminal has an itemType attribute: not
possible for a terminal to have multiple parents.
Gudge: yes
Jacek: would like to switch itemType and xsi:type.
Gudge: fine. So if says arrayOfInteger, and then it's an age.
Ray: new in 1.1, array element can only have one parent?
Gudge: no, just XML.
Ray: we have graphs, so could have several ancestors?
Jacek: through accessors.
Noah: there's the graph, and the its encoding.
Gudge: I was talking about the encoding, not the graph.
Noah: we have said id's on hrefs don't count?
Gudge: yes, we have covered this. Otherwise it would blow up.
Asir: complete rewrite of section 4, part2
Gudge: no, rewrite some of the encoding.
Volker: refactoring.
Noah: we are going to tell you exactly what a node is: an optional type name,
and for terminals the lexical value. Are going to flesh out chapter 2, and in
chapter 3 @@@.
DavidF: is this a good direction for the WG? take a couple more questions before.
Ray: as long as type name comes from xsi:type, can only have xml schema type.
Gudge: disagree;
Noah: counterexample: what if make a bunch of type names, like rectangle.
Ray: can't be carried via xsi:type.
Noah: encoding rules don't allow you to do netscape:type, since encoding does
not allow you to add your own attribute; but could still provide your own
encoding.
Ray: @@@
Noah: what does that mean when there is no schema to validate? don't require
validation? don't require anything that needs a schema to open and read.
Ray: fine if don't open the document and read it? Having schema can be useful
in decoding process.
Gudge: don't mandate schema. Could have said: don't validate, but must have
schema.
Ray: xsi:type means there is a schema.
Noah: schema type says @@@
DavidF: would like to take this particular part of the discussion offline.
Some other questions?
Asir: base64 type currently requires schema?
Jacek: goes the other way: xsi:binary is usually mapped to array of bytes.
Simple type from xml schema and encoding point of view, sugar on top of our
section.
Gudge: simple types are going to disappear, though?
Jacek: built-in, so don't dissappear.
Noah: nothing ever required that '003' and '3' were the same thing. This is
were you are getting base64 back. The node will contain the hex characters
from base64. The schema would tell you what this is. Makes sense?
Asir: makes sense to move to appendix. Opaquearray represented as base64, not
sure if can move away from schema...
Noah: may need to reserve another name which is a W3C type name (opaqueArray).
Gudge: could just bin it; why do we need this to be special?
Noah: for interop, where validating or not, @@@
Gudge: people might be pissed off if cannot serialize array.
Noah: even for integers.
DavidF: is this enough to mandate a proposal? Asir?
Asir: yes for having some proposed text.
[General assentment otherwise]
Asir: deadline?
Noah: in the background?
Gudge: during uninteresting parts of plenary? Delay appendix?
DavidF: need appendix as well. Before two weeks, but not today or tomorrow.
Noah: next week is bad until thursday.
DavidF: come back with a time estimate later today.
Issue 48
--------
DavidF: said yesterday would come back to it today.
MarcH: sent note yesterday to WG. Resolution which was accepted came out of an
IETF meeting; I just typed it in.
MarcH: resolution text actually reflects what the WG decided to do. Document
was not updated.
DavidF: option (ii) from the resolution was the issue. Double dependance on
data model and encoding. RPC dependency on encoding is an issue; dependency on
data model is ok.
Jacek: don't think keeping this resolution will change things much practically.
MarcH: no strong opinion either way. Wonder interop results if RPC choose
different encoding?
Noah: see where Jacek is going. This sentence tracks back to me.
MarcH: which sentence?
Noah: That SOAP arguments is a struct and be represented by any. What if decide
if the graph is wrong? WSDL can not model graphs. Would be nice that when WSDL
solves that issue, don't have to reopen the SOAP spec. Struggling with this.
Jacek: in RPC task force, proposed model rpc with elements and sub-elements,
and no data model. Completely free us of any dependance; but task force decided
to go the other route: rpc depends on data model.
Noah: didn't want to open the issue now, wanted to make it possible to use
other encodings in the future. Otherwise our spec will have either to be
edited, or will no longer be used (for this point).
MarcH: wsdl problem is dependency on data model?
Noah: ok
Jacek: uncomfortable if does not depend on struct.
DavidF: not proposing to do this now.
Jacek: can dig proposal i made to the rpc task force.
DavidF: no, we don't want to do this now. Proposing not to reopen issue.
Noah: so means to change the spec?
DavidF: yes, but just because the spec does not reflect the resolution.
Noah: fine.
DavidF: unless any concrete proposal to change the resolution, propose to move
forward.
MarcH: clarification to encoding will change this?
Gudge: no.
Henrik: for the minutes, @@@
Noah: can't decide if right. Do you think we should go back?
Henrik: more comfortable with what is in the spec today, not the resolution.
Noah: @@@
MarcH: only deals with graph that are trees?
Noah: yes.
DavidF: consensus for leaving the text as is?
MarcH: if conforms to rpc, but can't talk to someone using a different encoding...
Gudge: where in the spec does it say we are dependent on something?
MarcH: says uses struct, hence dependency.
DavidF: top of rpc section.
Noah: says other encoding is possible.
Gudge: so says nothing.
MarcH: keep it like this.
Noah: prefer @@@
MarcH: thought said didn't like this?
Noah: do you think the sentence in the spec means anything dependable?
MarcH: no; but need to be explicit in the right way if want dependency.
Ray:
Jacek: have a struct, hence data model.
Noah: so this is why wants to make it explicit.
DavidF: make it explicit.
Gudge: @@@
DavidF: proposal that rpc convention dependant on our underlying data model?
Gudge: yes, this is the proposal
DavidF: no objection.
MarcH: do we need to change the archive?
DavidF: no, send another email to xml-comments.
Asir: could we deal with 185 now, so could attend schema meeting?
DavidF: happy to entertain that. Is this dependent on 184 and 180?
Gudge: could deal with that...
Asir: ...or postpone until I'm back?
Jacek: current data model and encoding allow generic compound types: members
are accessed either by name, position or both. This "both" is the issue. Both
means: first by position, then by name, or the other way round.
Two proposal:
1) remove term generic compound type, and don't allow both access, since
can be done through arrays;
2) distinguish two approaches;
3) asir says, i think, generic compound types useful for modelling things
which are neither structure nor arrays, leave it to the application,
which i disagree with.
DavidF: does this reflect your position, asir?
Asir: yes. Generic compound type is large part of the data model, fundamental,
first class type. Jacek proposes array of struct, or struct of array. But make
an assumption that you know in advance whether the name or position is
important to you. This assumption takes away the advantage of generic compound
types. Not guaranteed that receiving end will reproduce this adequately, either
struct of array or array of struct. Other point is mismatch in expectation.
For us, data model is generalization of programming language and database data
model. Other question i have been asked: why not use XML directly? well,
generic compound types cannot be represented in xml directly, still need data
model and encoding rules to serialize. Propose status quo. Any change would
mean to change our encoding.
Dietmar: for my understanding, could you explain why there is a problem with
generic compound type, jacek?
Jacek: data structure is different if accessing first by name, then by
position or vice versa. For example, if select 3rd, then access "foo", first
thing is an array, then struct.
DavidF: answering question?
Dietmar: so operations are not commutative, but what is the problem?
Jacek: implementation has to support both, has to be done at application
level, cannot be done within the encoding, so just like if had raw xml.
DavidF: strong opinion?
Gudge: there were two proposals, so Asir could leave with writing both proposal?
Asir: no, more complicated and does not give me what i want.
MarcH: asir, you said could not use xml as it stands to transfer multistruct,
but this is exactly what the encoding does, so why is it you can't use xml?
Asir: i asked the question myself and could not answer it clearly. Generic
compound types is part of the solution for us. Can't represent arrays,
integers, byte arrays, etc in xml, so have to use encoding anyway. Does this
answer the question?
MarcH: no.
DavidF: have a use case for somebody needing this. Jacek, you say unneeded
complexity. No strong view in the room; between the two of you. So if someone
has a use case, need to be sympathetic.
MarcH: don't know of any programming language construct that directly supports
multistruct. Wonder whether lack of concern for this issue does not come from
lack of implementation. What are your data structures?
Asir: can't say more on our data structures, sorry.
Ray: @@@
JohnI: would contradict that statement. Coming from messaging background,
what is in there at the moment is a well accepted technique for mapping to
two different models.
Noah: what are you recommending?
JohnI: depends on the degree of grief each can support.
Jacek: apparent contradiction in Asir and JohnI: apparent compound type allow
you a degree of freedom, since client and receiver can intrepret the data in
different ways. Already have structs and arrays, when choosing one, choose
what is important for you. In the messaging environment, different models on
each side; transform the data from one data model to the other.
JohnI: transformation can be done at different places: intermediary,
intermediate format (multi-struct).
StuartW: may not be helpfull, but... not be closely monitoring ietf work.
Could only find one reference to multistruct: in an editorial note.
Asir: same thing as generic compound type.
Noah: soap implementers often raise issue that soap does not support general
programming data structures like hashmap. To what extent do generic compound
types help provide such general programming languages constructs?
MarcH: different to hashmap, since generic compound types have position; not
needed for hashmap.
Noah: would understand the other way round, if position was important but was
not in encoding; but for hashmap, position is just redundant.
MarcH: mixmatch between structs and arrays.
Noah: people feel order is important?
MarcH: in generic compound type, yes.
MarcH: other question: does proposed work on encoding (Noah+Gudge) have any
impact on this issue?
Gudge: no, don't think our work would preclude generic compound type.
DavidF: consensus, or leaning towards changing the status quo? No strong
feeling one way of the other, so generally in this type of situation status
quo prevails.
Gudge: asir, since only people supporting generic compound type, why not
use your own encoding? Since your stuff at both, why not do it your own way.
Asir: not only ones using it, interoperating with other products, so need it;
no need to answer other part of the question, then.
DavidF: a) changing status quo; b) keep status quo.
DavidF: a) ?
DavidF: 9 people
DavidF: b) ?
DavidF: about same number. Straw poll, rough. Does anybody have to change
the status quo?
[no one]
Henrik: observation: going to last call, it's always easier to remove stuff
that add stuff.
Noah: in schema, at about same time, signalled areas whether question had
been raised. Make decision in best interest of the spec, and highlight this
section by ednote.
DavidF: no consensus. Option: ask feedback on this particular issue. Interop
is an important issue. We will be skipping the CR phase, but will still have
to show interop for our spec. So if only one implementation with multistruct,
that tells us something.
Jacek: don't know of any implementation.
DavidF: proposal: leave generic compound type, and ask for feedback. Go into
last call with that as priority feedback. This raises the level of this
issue. Acceptable to the group?
[general assentment]
DavidF: the original resolution text was to change status quo, so should
leave issue open. The feedback on the draft
Jacek: can we go to last call with issue open?
DavidF: yes.
Yves: mark as postponed?
DavidF: yes.
Henrik: add action?
DavidF: editors should add appropriate piece of text.
DavidF: half-hour break.
Issue 78
--------
Jacek: difficult to know which element is the rpc element; also @@@.
Proposed resolution: clarify root section, such that true serializations
are marked as root="true", others marked as root="false", but only if
not obvious.
DavidF: clarification: criteria for not being "obvious" root?
Jacek: for rpc or more generally? For rpc, all but one is marked as
root="true", so ok.
Gudge: so default behviour if no default root attribute is that it is the root?
Jacek: in rpc yes...
Gudge: but say that attribute does have default value. So error if no
attribute, either true or false?
MarcH: need a new fault?
Gudge: how many roots do we anticipate?
Jacek: only one (for rpc)?
Gudge: so why not rewrite the text accordingly?
Jacek: @@@, and also in 1.1, usual practice is not to mark roots.
Henrik: similar argument: long discussion on soapbuilders: root attribute
is as obscure as can possibly be. Also, clarified that rpc is modelled as
struct...
Jacek: ... one struct...
Henrik: ... isn't a root unless marked so.
MarcH: before break, turn resolution rpc issue 48. If root attribute for rpc,
explicit dependency on encoding.
Jacek: mark all the non roots as root="false".
Gudge: rpc only one struct?
Jacek: yes.
Gudge: so exactly one child element?
Jacek: no.
Gudge: thought we had got rid of it?
MarcH: no.
Jacek: if follow the rules closely, nothing we don't say is allowed. Hm...
everything we do say is mandatory. But people carry soap 1.1 practice, which
we don't mention in 1.2 except for the root attribute.
DavidF: so clarification is not enough?
Jacek: of the root attribute usage? That's ok. If I had read the spec, first,
I would never have thought serialization roots are independent, but this is
current practice in soap 1.1. Soap root section is unclear.
Gudge: Henrik put to me suggestion that root is not part of the data model...
Henrik: ... because it is not just soap. At least you would have a mechanism
for saying you are here.
Gudge: say only ever one root.
Henrik: could have several root...
Gudge: ... in rpc there is only one.
MarcH: modify that sentence in the proposal: break that sentence.
DavidF: settling on change in data model?
MarcH: yes.
Gudge: would be best solution.
DavidF: need action.
Gudge: insert the notion of root into the data model.
DavidF: do we need to see this before moving to actual text? Any order for
doing this?
Gudge: since eds will be rewriting sections 2 and 3 anyway...
DavidF: any other changes? in encoding section? do we need to make any
reference from encoding to data model?
Jacek: no, already there.
MarcH: in current text, says roots may be marked... Any default value in
encoding?
Jacek: no.
MarcH: so only specify no root atribute applies to rpc?
Gudge: weird to me as well. Why not have root=false as default, and root=true
for the serialization root? since there will be fewer roots than non-roots?
DavidF: would change the proposed resolution, but would simplify it?
To the WG: require the root to be marked?
Henrik: so default would be false, not unknown?
StuartW: what if only one single element? would be the only root?
Jacek: could only do that in the encoding.
Gudge: if node with only inbound edges, root.
DavidF: but what if @@@
Gudge: stuart, thanks for pointing this out!
Henrik: @@@
Gudge: question was, if it is obvious, do you need to label it? If there is
only one node, it is obvious, do you really need to label it?
Jacek: even a single node, same graph, can be modelled as two elements. So
just mark it as root.
DavidF: so have to mark it as root? So this changes this proposal. Is this
the direction we want to go.
[general agreement]
DavidF: Jacek, appropriate person to come up with revised proposal. Also
need to take into account MarcH's comment.
Jacek: the last part would go.
DavidF: changes section 5, and removes proposed text from rpc. Could do this
over lunch.
MarcH: probably also needs to say, if not using soap encoding, should mark
the root.
Jacek: data model has notion of root; so if encoding allows something funky,
like ours does, then... Can do this over lunch if access to some computer.
Issue 184
---------
DavidF: Gudge, handle in Asir's absence?
Gudge: yes. From type perspective, llow id and ref. Notation should not be
there, since schema specs disallows this as either type of attribute or
element, or as base type either unless provides an enumaration. So, since
can't know what the enumeration looks like, cannot use it. In fact, already
gone; sent email couple of months ago, no objection received. Also, need
health warning: is discouraged by schema spec. If not health warning, take
away alltogether (id, ref).
Jacek: needs these special types since dependency on schema.
DavidF: take out notation?
[no objection]
DavidF: also take out id and ref? Strong opinion?
[none]
Gudge: so need health warning.
Jacek: warning is enough, since references schema spec, which includes real
health warning.
Gudge: so only say something about attribute.
[loud agreement]
Gudge: will send mail to xmlp-comments.
Issue 180
---------
DavidF: parameter ordering. Henrik?
Henrik: in rpc section, current version at least. Talks about in/out
parameters. Notion of struct, serialize about order of method signature,
but don't define method signature, don't talk about ordering, whether
significant or not. Recommendendation: ...
Gudge: ... also, say something different for the response!
Henrik: yes. In 1.1, did not specify result, but now do.
Three options:
a) model method calls and responses.
b) make it consistent between request and response.
c) don't model method signature at all and discuss ordering.
ETF recommends option c).
DavidF: discussion?
[none]
DavidF: any objection?
MarcH: some discussion. Was part of ETF; some discomfort to removing
ordering. Part of status quo, doesn't see strong reason for change.
Jacek: order is insignificant.
Gudge: have to change status quo to align request or response, either
have ordering for both or none. No strong opinions.
StuartW: variable number of parameters, ie. printf?
Jacek: no we don't.
Noah: we can call them, we don't model them in general.
Ray: also have to have unique names.
Noah: so, like where this is heading, but nervous about Jacek saying structs
are not ordered. Seems essential to me that convey order of our arguments,
since so many languages use position of arguments. Can proposed change
support that? Is this a case for multistruct (says he reluctantly)?
MarcH: this is the description of my concern.
Henrik: does not say ordering is significant or not. If order is significant,
like printf, say it and serialize it accordingly.
StuartW: says unordered...
Jacek: ... only accesed by name.
Henrik: slight different point: access by name. But does not saying whether
the order is significant or not.
Jacek: but says have to take them by name.
Noah: have to fix structs, ordered or partially ordered, or @@@
Jacek: WSDL has an attribute to specify whether has an order or not.
Noah: WSDL level solution is no acceptable; said we should be WSDL
independent. Might as well say rpc does not work without WSDL.
Ray: does WSDL support var args?
Jacek: said in the past accessed by name.
Noah: ok if history, but assumed order.
Ray: @@@
Jacek: violates our convention that parameters are named.
Noah: most programming languages use position.
Jacek: but also have name.
Noah: usually the parameters, not the arguments are named.
Henrik: true, but seems to me at a higher level.
Noah: true, but don't see how to convey the order. If throw arguments into
a bag, cannot retrieve the order later.
Jacek: not a bag.
Noah: so if not using WSDL, use a special naming convention?
Jacek: no, using metadata, such as for type.
Noah: would proposed that arguments be named R1, R2, etc. to convey the order.
Gudge: @@@
Noah: but gets lots in the struct.
MarcH: and in some languages gets lost.
Gudge: @@@. So bin section 4, 3 and 2.
Jacek: out of our logical charter; but necessary for acceptance.
MarcH: could have struct true restriction of multistruct, order significant,
but name is significant.
Noah: what about my friendly amendment above? named R1, R2, etc. if order
important; just a convention to promote interop with such languages.
Gudge: R1, R2, R3, R4, R5, R6, R7, R8, etc.
Noah: don't want to write the corresponding schema!
JohnI: varargs?
Noah: different issue.
DavidF: clarification: suggestion to accept c) and add a statement that, to
model arguements only defined by position, to use convetion...
Noah: how much of this should be normative (Henrik's concern). Have to
reserve namespace, but also reserve the names?
StuartW: lexicographic ordering?
Noah: need to specify.
Gudge: like John's proposal: use either struct or array?
Noah: @@@
JohnI: just taking up your proposal, R1, R2 etc is equivalent to array.
DavidF: proceed with struct or array?
[yes]
Noah: so only model where name is significant or order is?
Jean-Jacques: what if different conventions on sending and receiving side?
Noah: mapping language issue, out of scope.
DavidF: JohnI to draft proposal?
Ray: WSDL?
Jacek: no look at WSDL, SOAP WG.
DavidF: John, over lunch?
JohnI: limited connectivity?
DavidF: end of the week type deadline?
JohnI: end of tomorrow.
DavidF: finished with the ETF issues.
Issue 137
---------
DavidF: no text?
Noah: text in 30 seconds.
DavidF: how big?
Noah: several paragraphs.
DavidF: jump to 59
Issue 59
---------
Jacek: easy one. Requirements say can mandate a particular character
encoding. Infoset based, so character encoding only transport binding.
Proposed HTTP binding does not mandate any character encoding. XML requires
XML processor handle UTF-8 and UTF-16. Issues with other encodings are know.
Other transport bindings may mandate character encodings.
DavidF: discussion?
[none]
DavidF: objection?
Noah: XML spec is little funny in specifying what a processor can do. Why
are we saying UTF-8/16 are mandatory? Why not leave it to the binding? Can
live with this, though.
Jacek: text about UTF was supposed to be in binding.
DavidF: oh, not clear from the proposal.
Noah: does it mandate or not?
Jacek:
Noah: unclear then.
Jacek: can remove the last 4 lines.
DavidF: recap: this piece would go into the transport binding general
section; and the "The SOAP HTTP binding does not mandfate any character
encoding" ... would go into the encoding section.
Noah: HTTP binding spec should be clear about this. If clear enough already,
fine; but if any question whether ok to do this or that, should say so.
Jacek: ongoing discussion. In TAG list, where do you get that information?
Noah: so implicitely adopt whatever they come up with? Should say it explicitly.
Gudge: how do you figure out what encoding is being used is a different issue.
DavidF: should we raise a new issue (how to specify character encoding)?
Gudge: HTTP spec tells you how to specify encoding for a given body; XML for
a given serialization...
DavidF: ... should just make a reference?
Henrik: make it explicity.
Noah: specing a two ended thing, the sender and the receiver, so precludes
us from saying what we mean, and if no encoding specified, interop problems.
These are choices we should make and document.
Henrik: interop concerns, yes. What is the cost and benefit of mandating
just one encoding, for example if the rest of the world moves in a different
direction.
Noah: would republish the spec then. Proposed to mandate at least UTF-8.
Maybe UTF-16 if too english biais.
Jacek: if only UTF-16, @@@
Noah: we are not just reading documents, but also writing them.
Henrik: HTTP allows negociation of character set used.
Noah: need to say so, because WSDL needs it. If see WSDL endpoint that uses
HTTP binding or Jacek's binding, @@@ Nervous about performance if negociation.
Jacek: No pb.
DavidF: two rounds.
Jacek: oh, ok.
Henrik: outside soap, before you see the first message, need to know what
to send.
Noah: should be part of the binding name. Assumption: two ends agree on
state machine.
Henrik: follow HTTP convention for figuring out character sets.
Noah: so what does it say how to post?
Jacek: by failure.
Noah: so 2 or 3 roundtrips. Don't want this to be the case.
Gudge: what if say must support UTF-8/16? Objection.
[none]
Gudge: done!
DavidF: thanks Gudge!
Noah: good suggestion.
DavidF: so, recap, take this pagagraph, put in the general binding
description; add Gudge's words to the HTTP binding (using standard
HTTP mechanims).
Noah: @@@ should say if clean.
DavidF: clean now?
Jacek: agree.
@@@: at least?
Gudge: yes!
MarkB: for xml serialization?
Henrik: for this particular HTTP binding.
Henrik: missed an action?
DavidF: no. What goes into HTTP binding: at least UTF-8 and UTF-16, and use
standard HTTP mechanism for finding out which one is used.
Jacek: other action to xmlp-comments.
DavidF: so agreement. Done. Jacek, send mail to xmlp-comments?
Issue 181
---------
Gudge: about what is it that goes identifies a node? Add "identified by
URI" and @@@.
StuartW: use MAY instead of MUST?
Gudge: @@@
MarcH: not faultrole...
Gudge: didn't know how to choose one, if several...
MarcH: or faultroles?
Gudge: didn't think was useful.
MarcH: might be useful.
Jacek: will be used for debugging, so Gudge's proposal is ok.
MarcH: don't have routing yet, so faultactor is meaningless, should have
faultrole.
Henrik: have messaging flowing around. Makes sense to who failed.
MarcH: my concern is slighly different. If you receive a fault back, what
effect would it have on your processing? I would content none.
Henrik: if, for example, two nodes with same service, do the same role,
send message to the two of them, you need more than the role back from
the failure, eg authenticate.
MarcH: mismatch between targetting and fault.
Gudge: soap node identified by uris?
MarcH: soap roles do. What with reaching the node with SMTP or HTTP?
Henrik: @@@
Noah: Web architecture says shouldn't adress this question. Could make a
3rd URL which represents the node, independent of how you got there?
DavidF: our boston friends expect that we start again at a specific time,
so propose we break down now.
Afternoon, February 26
Minutes missing