Non-trivial editorial comments

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

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>

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>


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.

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

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

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

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?

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.

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.

Page : 13 Line : 267 Author : AK 08/16/2005
Change it to say : "... mustUnderstand attribute with a value of 1/true ...'
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)

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.

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

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

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

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

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.

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.

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)

Page : 26 Line : 678 Author : AK 08/16/2005
I assume this is intended to say fault [subcode]. Is that correct?
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.

Page : 32 Line : 818 Author : AK 08/16/2005
need a soap 1.2 ref too

Page : 32 Line : 820 Author : AK 08/16/2005
never used. need to include this (or IRI) ref where ever 2396 is used

Page : 32 Line : 825 Author : AK 08/16/2005
never used. this could be reference where we talk about schema

Page : 32 Line : 827 Author : AK 08/16/2005
never used. could be used where we talk about schema types

Page : 32 Line : 833 Author : AK 08/16/2005
this isn't used either. Why is this a normative reference?

Page : 32 Line : 836 Author : AK 08/16/2005
should be removed, never used

Page : 33 Line : 842 Author : AK 08/16/2005
none of these references are used

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.

--------------------

WS-ReliableMessaging-v1[1].0-wd-01.sxw

WS-ReliableMessaging-v1[1].0-wd-01.pdf