W3C home > Mailing lists > Public > www-archive@w3.org > August 2002

RE: Edtodo is now uptodate

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Sat, 24 Aug 2002 21:18:11 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D08A34D49@red-msg-07.redmond.corp.microsoft.com>
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.

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 
>> 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.


>> 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?


>> 335: I don't think we need to change it, it is only an example...


>> 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).


>> 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.


>> 353b: Provide at least one example for each section

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

>> 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,


[1] http://www.w3.org/International/Group/2002/charmod-lc/#C062
Received on Sunday, 25 August 2002 00:18:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:52 UTC