OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] List of Bob's NEW issues (really only six) well, ok seven


My opinions inline.

 

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, June 29, 2006 6:45 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] List of Bob's NEW issues (really only six) well, ok seven

 


Comments on Bob's issues:

Apx C examples http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00217.html
These sample message flows are tied to figure 2 - do we really want to update that one too? I don't really care much except it does make more work for the monkeys  :-)

MG: I don’t mind seeing these examples added, however I think the tie to figure 2 is a perfect excuse to avoid the work altogether. I’m fine with seeing the message examples added with or without the update to figure 2. Someone will have to produce them though.

  

Sequence Expiry http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00216.html
Do we really need an entire new section for this or can we just add a line of text to where Expires is used saying something like:
        This value indicates the time at which the Sequence SHOULD be terminated.  
Or just change sentences like:
        This element, if present, of type xs:duration specifies the duration for the offered Sequence.
To:
        This element, if present, of type xs:duration specified the duration of time until the Sequence SHOULD be terminated.
MG: I have not had enough time to think about this one. I am not going to be ready to make a decision about this on today’s call.

 


Rollover by RM Source http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00212.html
on 1) that an impl detail, nothing on the wire from a spec perspective
on 2) an impl choice - it may not choose to close/terminate the sequence at all
I suggest: Close w/no action
MG: I haven’t thought deeply about this one, but that was my first inclination as well.

 


What does not receive mean? http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00200.html
Just editoral, I'm ok with it.
MG: I’m not sure, I can try to be ready to decide on this one on the call but no promises.


Can’t respond if Sequence not known http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00193.html
Editorial, not sure its needed since the definition of UnknownSeq fault says its sent whenever we see an RM element referring to a Seq we don't know about, so do we really need to say that for each and every RM element?  Seems a bit noisy but I'm not going to lay down in the road over it.  My preference would be to close w/no action since I think the Fault text already covers this.
MG: Agree the fault text already covers it, but I’m fine with adding this.

 

Terminate sequence, fault not specified http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00192.html
See previous issue comment - this is getting a bit verbose.
MG: Agree, still I’m OK with it.

 

Add detail and specificity to fault descriptions http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00190.html
I would like to see a specific proposal (actual proposed text) before I can know for sure if I like the idea of this or not.
MG: I’m having a similar problem with this one. 

thanks
-Doug



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]