- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Sat, 24 Aug 2002 21:18:11 -0700
- To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "Martin Gudgin" <mgudgin@microsoft.com>
- Cc: "W3C Public Archive" <www-archive@w3.org>, "Marc Hadley" <marc.hadley@sun.com>, "Nilo Mitra" <EUSNILM@am1.ericsson.se>, "Noah Mendelson" <noah_mendelsohn@us.ibm.com>
Sorry for the delay--here are my comments... >> 221: I think the resolution is problematic. >> >Agree. Yup... I will follow-up on dist-app. >> 286: Add '(which may or may not also be SOAP >intermediaries)' to first >> note? >> >Sounds reasonnable. Yes, although there are some combinations that violate HTTP and some that don't. I think it is ok that we don't go into that here. >> 289: What does an intermediary do when it receives a fault? Is the >> fault guaranteed to be passed on to the original sender ( or >previous >> intermediary)? >> > >Since we don't indicate what happens when faults are generated >in the first place, I think the most we can say is that >intermediaries MAY forward fault messages. > >However, I am wondering whether this is not raising a deeper >issue, which is how intermediaries forward response messages. >I think sections 2.7.* are written from the POV of request >messages; do they cover adequately response messages? I think so: As we don't say anything about how the forwarding feature is defined for any SOAP messages other than stating that it is a feature, this would also apply to SOAP faults--they are just a certain type of SOAP messages. >> 334a: Mention SOAP Response MEP???? I don't think we need to. >> >I also don't think we should. +1 >> 334b: Seems to me that MEPs are one of the extensibility points in >> SOAP... So what do we need to say??? >> >I'm confused by the issue as well. Ignore? +1 >> 335: I don't think we need to change it, it is only an example... >> >Agree. +1 >> 352a: When refering to the QNames of types use QName production ( >> prefix:localname ) rather than 'localname' >> >I think this would improve readability (although, strictly >speaking, prefix should be replaced by the corresponding URI ;-)). Yeah, but as I think we have the table up front in the document, I think that's fine. >> 352b: Use textual identifiers for references rather than numerics >> >I believe I have done this already about two months ago, after >this were pointed out for WSDL... BTW, this is not a >stylesheet issue, we only need to change the key in the bibtex >entry (or whatever the XML production name is). ok >> 352d: Ensure all occurences of Infoset properties appear in square >> brackets; e.g. '[specified]' rather than 'specified'. >> >The better long term solution would be to create and use a new >XML element. We should then s/[/<prop>/. Hmm, now they look like [references]--I think I would prefer some other stylistic solution. >> 353a: Provide examples of 'struct' and 'array' from some programming >> language >> >I agree with Marc, we should not do this. I also think this is >out of scope for the primer. yup >> 353b: Provide at least one example for each section >> >Possibly. I would say no--we just moved all examples to primer. >> 353c: I propose we change the section title from 'Rules for encoding >> Graphs in XML' to 'Mapping between XML and the SOAP Data Model' or >> some such. 20020820 MJG >> >Works for me. > >> 357: Change DataEncodingUnknown to SOAPEncodingUnknown >> >Sounds good. I actually prefer DataEncodingUnknown because "SOAPEncoding" is used to mean the encoding defined in part 2 while this subcode can apply to any encoding. >> 373: suspect this issue really needs to be kicked 'upstairs' to the >> WG. I don't understand this--their issue [1] says that we are not required to do this and I think we pushed back on this some time ago, no? Hope this makes sense, Henrik [1] http://www.w3.org/International/Group/2002/charmod-lc/#C062
Received on Sunday, 25 August 2002 00:18:43 UTC