RE: Edtodo is now uptodate

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