[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx-editors] Non-trivial editorial comments
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.
>>
>> --------------------
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]