[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx-editors] Non-trivial editorial comments
Finally, here are my comments.
It is not clear to me where we can fix as we like, and when we need to
consult the tc. Those that I agreed with are editorial and can be fixed
by us. Those which should probably raised to the tc are listed as new
issues.
Perhaps we can get the chairs to help us here.
--umit
> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Tuesday, Aug 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>
>
> 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.
+1. Ditto for the Policy doc.
>
> 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
>
+1
> 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 ..."
+1
>
> 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]).
Good idea.
>
> 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?
Yes, it is out of place. I would reword that paragraph a bit if we were
to move it to the relationships section to make it a bit more formal.
>
> 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.
+1
>
> 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.
I agree that it is out of place. Perhaps a separate Extensibility
Section clearly demarcated is necessary, whether in Section 1 or the end
of 3.
>
> Page : 13 Line : 267 Author : AK 08/16/2005
> Change it to say : "... mustUnderstand attribute with a value
> of 1/true ...'
It looks like a bug, not an editorial one. I am sure no-one intended
mU=0, but it would be good to post it to the group.
> 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)
I don't want to sound like TomJ, but you are right. This is an issue
which should be brought up to the tc, using WS-A as an example.
>
> 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.
Agreed. New issue should be circulated with the proposal.
>
> 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
Yes, a bug. We can correct it ourselves.
>
> 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'.
How about "included in a response message."
>
> 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
+1
>
> 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 ..."
New issue. Lets run it by tc.
>
> 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.
+1
>
> 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.
>
+1. New Issue.
> 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)
+1. We need to be clear on normative dependencies anyway.
>
> Page : 26 Line : 678 Author : AK 08/16/2005
> I assume this is intended to say fault [subcode]. Is that correct?
It is not clear. New issue.
> 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.
You are correct. This is an editorial issue which we should fix
following the oasis ref style. Unfortunately, they are not very
prescriptive about this. I prefer Author, Title.
>
> 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
Ok, lets delete them and bring the proposal as one tc comment, if
necessary.
>
> Page : 34 Line : 860 Author : AK 08/16/2005
> why is this import needed?
>
It is needed. See 990. This is to validate as it is written.
> 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
+1. Good practice.
>
> Page : 35 Line : 887 Author : AK 08/16/2005
> should we restrict the unsignedLongs to be > 0?
New Issue.
>
> 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.
Sounds like a bug to me. New Issue.
>
> Page : 36 Line : 931 Author : AK 08/16/2005
> for consistency should we call this FaultCodeType
+1
> Page : 36 Line : 943 Author : AK 08/16/2005
> should this be tns:FaultCodes instead of xs:QName?
Not sure. New Issue.
>
> Page : 36 Line : 963 Author : AK 08/16/2005
> Schema does not contain SecurityTokenReference but the spec does
New Issue.
>
> Page : 48 Line : 1254 Author : AK 08/16/2005
> why is this imported? It is never used.
See line 1272
>
> --------------------
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]