RE: [ws-rx-editors] Non-trivial editorial comments

["Patil, Sanjay" <sanjay.patil@sap.com>]

Are new issues already raised for the substantial changes? 

Sorry for asking this. I am still working on my pending emails and may
be this is already taken care.

Thanks,
Sanjay 

>-----Original Message-----
>From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
>Sent: Sunday, Sep 11, 2005 23:29 PM
>To: Marc Goodner
>Cc: ws-rx-editors@lists.oasis-open.org
>Subject: Re: [ws-rx-editors] Non-trivial editorial comments
>
>I have not heard any other response (from the other editors) on the 
>non-trivial changes. Any other comments?
>
>Marc: my responses below within <ask></ask>. Thanks for reviewing the 
>changes and sending comments.
>
>I have gotten one response on the trivial changes (from Doug 
>saying that 
>it looked ok to him). If I don't hear anything about the trivial 
>changes, I'll forward it to the TC before this week's call.
>
>-Anish
>--
>
>
>Marc Goodner wrote:
>> Wow, that's a lot of changes. I have detailed comments below <mg>. I
>> think some of these are fine, some I think you should raise editorial
>> issues. I also promised to look into some of your proposed 
>changes that
>> I can't answer, I'll try to respond by tomorrow.
>> 
>> I think when the next round of pending issues gets 
>incorporated here a
>> WD and redline should be produced with a similar note style 
>to what you
>> have here. Instead of commenting on what editorial changes 
>you want to
>> make it should explain the redline editorial changes. I 
>would advise to
>> play it safe and raise an editorial issue if you ever think 
>a change is
>> substantive or sensitive.
>> 
>> Regards,
>> Marc g
>> 
>> 
>> -----Original Message-----
>> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
>> Sent: Tuesday, August 16, 2005 6:29 PM
>> To: ws-rx-editors@lists.oasis-open.org
>> Subject: [ws-rx-editors] Non-trivial editorial comments
>> 
>> All,
>> 
>> Attached are the .sxw and .pdf files that include the non-trivial
>> editorial comments (in the form of OO Notes) that I mentioned in 
>> my previous email.
>> 
>> The attached .sxw file contains OO Notes (equivalent of 
>> WS-Word/Acrobat Comments). But the OO Notes are hard to read and 
>> list (not very helpful compared to Word/Acrobat). They can only 
>> be listed when printing.
>> 
>> While converting to PDF, OO provides an option to list the Notes 
>> at the end of every page (on which they occur). The attached PDF 
>> file contains such listing.
>> 
>> There are only three ways to look at the Notes: (1) look at the 
>> PDF, (2) move your cursor over the tiny yellow rectangle (where 
>> the comment appears) in .sxw file, (3) print the doc and specify 
>> in the options that you want the Notes.
>> 
>> To make it easier, I have listed all the Notes at the end of 
>> this email.
>> 
>> I have turned the change bars off to remove the clutter from 
>> the previous edit. Please note that I have made two new inlined
>>  changes:
>> 
>> Line 268:
>> <previous>
>> children and/or attributes MAY be added at the indicated extension
>> points
>> </previous>
>> <new>
>> children elements and/or attributes MAY be added at the indicated
>> extension points
>> </new>
>> 
>> <mg>Seems OK
>> 
>
><ask>
>I'll include this as part of the trivial changes.
></ask>
>
>> Lines 346-347:
>> <previous>
>> <wsrm:SequenceAcknowledgement> header block at any point.  
>The timing of
>> acknowledgements can be advertised
>> <previous>
>> <new>
>> <wsrm:SequenceAcknowledgement> header block at any point during which
>> the sequence is valid.  The timing of acknowledgements can 
>be advertised
>> </new>
>> 
>> <mg>Seems OK
>> 
>
><ask>
>I'll include this as part of the trivial changes.
></ask>
>
>> 
>> Comments?
>> 
>> -Anish
>> --
>> 
>> 
>> Summary of Notes:
>> --------------------
>> Page : 2 Line : 22 Author : AK 08/16/2005
>> This seems out of place. I would like to suggest that we add a new
>> subsection under
>> introduction called 'Relation to other specification'. We can include
>> this para as well as
>> stuff about conformance to WS-Addressing in it.
>> 
>> <mg>I'm not as convinced it needs to be moved, I'm open to the
>> suggestion though.
>> 
>
><ask>
>That section just looks out of place. The usual order is: abstract, 
>followed by Introduction. A lot of spec (eg soap 1.2 etc) include a 
>'relation to other specs' where they talk about related specs, 
>restrictions if any, etc etc. I also think that the spec needs a clear 
>statement about conformance to WS-Addressing . WS-Addr is one WS spec 
>that is absolutely required (where as SOAP/WSDL are not). All of this 
>logically seems to belong to a section such as 'Relation to 
>other spec'. 
>Also see the comment about line 120. But I'm open to other 
>suggestions too.
>
>[.1] http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#reltoxml
>
></ask>
>
>> Page : 5 Line : 92 Author : AK 08/16/2005
>> It would be nice to use language similar or same as the
>> WS-Addressing/WSDL 2.0 spec
>> which use the same notation (modulo copyright concerns). This is of
>> course not critical,
>> just consistency across ws-* specs. Regardless, we do need to add
>> statements about what
>> {any} and @{any} mean
>> 
>> <mg>Agreed on the anys
>> 
>> Page : 6 Line : 109 Author : AK 08/16/2005
>> This is ambigious. How about replacing this stmt by something like:
>> "Elements defined by this specification below to the 
>following namespace
>> ..."
>> 
>> <mg>I don't really agree that it is ambiguous. Let me look 
>at some other
>> examples and respond.
>> 
>
><ask>
>Ok. Will wait for your response.
>The ambiguity is in -- what does it mean to implement a 
>namespace? What 
>we really want to say is that the elements defined in this particular 
>spec below to the http://schemas.xmlsoap.org/ws/2005/02/rm 
>namespace URI.
></ask>
>
>> Page : 6 Line : 118 Author : AK 08/16/2005
>> Add the following:
>> Namespace names of the general form "http://example.org/..."; and
>> "http://example.com/..."; represent application or 
>context-dependent URIs
>> (see RFC 2396
>> [RFC 2396]).
>> 
>> <mg> Sure
>> 
>> Page : 6 Line : 120 Author : AK 08/16/2005
>> This para shouldn't be under the 'namespace' subsection. How about
>> moving this to the
>> 'relationship with other spec' subsection?
>> 
>> <mg> Hmmm, I suppose
>> 
>> Page : 9 Line : 172 Author : AK 08/16/2005
>> This is the same definition as ws-addressing. I would like to suggest
>> that we just point to
>> the ws-addr spec for this.
>> 
>> <mg>I usually agree with points like that but I'm not so 
>sure we want to
>> remove the definition of Endpoint. Maybe a subsection of terms used
>> throughout this spec that are defined elsewhere? Still ugly.
>> 
>
><ask>
>Yes, that is ugly.
>But why would we not want to point to the WS-Addressing spec, 
>since the 
>meaning is exactly the same and there is a normative dependency on 
>WS-Addr spec anyway. WSRM talks about endpoints in the same way as 
>ws-addr does and uses EPRs to identify them which are defined in 
>WS-Addressing. Having a definition which is different from 
>WS-Addressing 
>but using EPRs to identify the endpoints would be very weird.
></ask>
>
>> Page : 13 Line : 239 Author : AK 08/16/2005
>> This paragraph is applicable to section 3 as well as section 
>4. Suggest
>> that we move this
>> to section 1.
>> 
>> <mg>Makes sense.
>> 
>> Page : 13 Line : 267 Author : AK 08/16/2005
>> Change it to say : "... mustUnderstand attribute with a 
>value of 1/true
>> ...'
>> 
>> <mg>Sure
>> 
>> Page : 13 Line : 270 Author : AK 08/16/2005
>> there are several reference to RFC2396. 2396 is obsoluted by 3986.
>> Or like ws-addressing we could move to IRIs (RFC 3987)
>> 
>> <mg>We might want to flag this one at a higher level than just an
>> editorial issue.
>> 
>
><ask>
>Agreed. This is much more than editorial.
></ask>
>
>> Page : 14 Line : 273 Author : AK 08/16/2005
>> The phrase 'based on schemas' (or 'based on schema to be passed') is
>> used anywhere
>> extensibility is defined. I don't understand this phrase. If the
>> intention is to say that the
>> extensibility attributes/elements must not be from the WSRM schema
>> ("##other") then
>> we should say exactly that.
>> 
>> <mg>I'd like to double check that one, I'll try to get an answer
>> tomorrow. Please bug me if I forget. (I've only got two hours
>> unaccounted for...)
>> 
>
><ask>
>considered yourself bugged. :-)
></ask>
>
>> Page : 14 Line : 294 Author : AK 08/16/2005
>> not quite accurate. I would like to suggest that we use the XPATH
>> notation used above.
>> I.e. /wsrm:Sequence/wsrm:LastMessage
>> 
>> <mg>Makes sense
>> 
>> Page : 15 Line : 313 Author : AK 08/16/2005
>> A better way to say 'return messages' is to say:
>> '... included in a response message, in the case of a 
>request-response
>> pattern'.
>> 
>> <mg>Sure, but a SequenceAcknowledgement does not necessarily 
>come back
>> on a response of a request-response mep which is probably why the
>> current wording is the way it is. I can certainly read over it easily
>> enough to get that would be a resp in a req/resp mep. I 
>think its fine
>> as is.
>> 
>
><ask>
>Thinking more about this, I think this is perhaps a 
>non-editorial issue. 
>It is not just a return or a response message that it can be included, 
>it can be included in any non-return message as well. I.e., consider a 
>bidirectional RM sequence (but over a one-way transport like an email 
>binding or over two different protocols). The messages sent in the 
>opposite direction may not be a response/return message and is sent as 
>an independent message. It should be perfectly ok (my 
>interpretation/opinion) to have a wsrm:SequenceAcknowledge 
>header blocks 
>on such unrelated messages.
></ask>
>
>> Page : 15 Line : 338 Author : AK 08/16/2005
>> should 'optional' and 'required' words in the spec be 
>converted to RFC
>> 2119 OPTIONAL
>> and REQUIRED. The occurrances seem to indicate the same 
>meaning as the
>> RFC
>> 
>> <mg>For lines 332 and 338 I think you are right. I can run 
>that around
>> here as well. I think this is a case by case and not a global search
>> replace though.
>> 
>
><ask>
>I should have better qualified my comment. I meant that this 
>be replaced 
>only in section 3.
></ask>
>
>> Page : 15 Line : 341 Author : AK 08/16/2005
>> Given that there can be multiple SeqAck headers in a message, an
>> accurate way of saying
>> this is:
>> "... MUST NOT be present if a sibling <wsrm:Nack> element is also
>> present ..."
>> 
>> <mg>I think you are right.
>> 
>> Page : 21 Line : 534 Author : AK 08/16/2005
>> too vague. A wsrm:Offer element can be in the extensibility point. A
>> better way would be
>> to use the xpath like syntax that is already being used.
>> 
>> <mg>I don't think that is vague. Maybe hard to understand 
>but not vague.
>> ;-) Anyway what would your proposed text be? I can't quite 
>work out what
>> xpath statement + wording would make that easier to grok.
>> 
>
><ask>
>It is not accurate for the following reason:
>Consider the case where there is an element -- 
>/wsrm:CreateSequence/myns:Foobar/wsrm:Offer
>
>In this case, the <wsrm:CreateSeqence> message does *contain* 
>wsrm:Offer 
>element, but that is not what we are concerned with.
>
>I would suggest replacing:
>"This element MUST be present if the corresponding 
><wsrm:CreateSequence> 
>message contained an <wsrm:Offer> element."
>
>with:
>"This element MUST be present if the corresponding 
><wsrm:CreateSequence> 
>message contained an /wsrm:CreateSequence/wsrm:Offer element."
>
></ask>
>
>> Page : 24 Line : 597 Author : AK 08/16/2005
>> The default fault action URI is defined only for the SOAP 
>binding and it
>> is meant only for
>> ws-addressing related faults. This para should be deleted OR specific
>> action(s) should be
>> defined for WSRM faults.
>> 
>> <mg>I think you should raise an editorial issue on this one.
>> 
>
><ask>
>Ok. Will do.
></ask>
>
>> Page : 24 Line : 598 Author : AK 08/16/2005
>> this means any version of ws-addressing that is used in the message.
>> If that is not the intend (which I don't think it is), we 
>need to tie it
>> down to a specific
>> version of WS-Addressing (W3C one)
>> 
>> <mg>I say make this part of the issue above. Note that an 
>issue needs to
>> be raised to add the W3C version of Addressing as well. I agree the
>> investigation should be done now but we should point to both the
>> contribution and the final Rec. I believe that the Rec will get out
>> before we're done.
>> 
>
><ask>
>Ok. Will do.
>I think WS-addr will be a REC before WSRM is done, as well.
></ask>
>
>> Page : 26 Line : 678 Author : AK 08/16/2005
>> I assume this is intended to say fault [subcode]. Is that correct?
>> 
>> <mg>Don't know, I'll add it to my investigate list.
>> 
>
><ask>
>Any input on this?
></ask>
>
>> Page : 32 Line : 813 Author : AK 08/16/2005
>> The reference style is inconsistent. Sometimes the author 
>name is listed
>> first, sometimes it
>> is title first.
>> 
>> <mg>Fix it.
>> 
>
><ask>
>will do.
></ask>
>
>> Page : 32 Line : 818 Author : AK 08/16/2005
>> need a soap 1.2 ref too
>> 
>> <mg>Yeah, seems like an oversight to not have it in the namespaces at
>> the beginning as well.
>> 
>
><ask>
>I'll go ahead and add it.
></ask>
>
>> Page : 32 Line : 820 Author : AK 08/16/2005
>> never used. need to include this (or IRI) ref where ever 2396 is used
>> 
>> <mg>Good catch.
>> 
>> Page : 32 Line : 825 Author : AK 08/16/2005
>> never used. this could be reference where we talk about schema
>> 
>> <mg>Good catch.
>> 
>> Page : 32 Line : 827 Author : AK 08/16/2005
>> never used. could be used where we talk about schema types
>> 
>> <mg>Good catch.
>> 
>> Page : 32 Line : 833 Author : AK 08/16/2005
>> this isn't used either. Why is this a normative reference?
>> 
>> <mg>The reference is not used but it should be where Secure 
>Conversation
>> is discussed in the Security Considerations section.
>> 
>
><ask>
>The question is, why is it normative?
>But this isn't an ed. question. I'll raise this as a separate issue.
>And you are right that it needs to be referenced from the Security 
>consideration section.
></ask>
>
>> Page : 32 Line : 836 Author : AK 08/16/2005
>> should be removed, never used
>> 
>> <mg>I thought there was reference to this somewhere. I'd 
>like to double
>> check this.
>> 
>
><ask>
>I searched for it, it is not there.
></ask>
>
>> Page : 33 Line : 842 Author : AK 08/16/2005
>> none of these references are used
>> 
>> <mg>I suppose so.
>> 
>> 
>> <mg>OK it's late I can't check the rest of that tonight. My 
>initials may
>> be mg, I may work for Microsoft, but I am NOT a human schema 
>processor.
>> 
>> Page : 34 Line : 860 Author : AK 08/16/2005
>> why is this import needed?
>> 
>> Page : 34 Line : 880 Author : AK 08/16/2005
>> all other types are non-anon types. Why is this an exception? for
>> consistency I would
>> suggest making this a non-anon type
>> 
>> Page : 35 Line : 887 Author : AK 08/16/2005
>> should we restrict the unsignedLongs to be > 0?
>> 
>> Page : 35 Line : 907 Author : AK 08/16/2005
>> The spec uses wsrm:MessageNumber not 
>wsrm:MaxMessageNumberUsed. The spec
>> also
>> says that if there is a diff between the schema and the spec then the
>> spec wins. But I'm not
>> sure if this is true in this case.
>> 
>> Page : 36 Line : 931 Author : AK 08/16/2005
>> for consistency should we call this FaultCodeType
>> Page : 36 Line : 943 Author : AK 08/16/2005
>> should this be tns:FaultCodes instead of xs:QName?
>> 
>> Page : 36 Line : 963 Author : AK 08/16/2005
>> Schema does not contain SecurityTokenReference but the spec does
>> 
>> Page : 48 Line : 1254 Author : AK 08/16/2005
>> why is this imported? It is never used.
>> 
>> --------------------
>