See also: IRC log
<trackbot> Date: 14 July 2009
<Bob> scribe: Sreedhara Narayanaswamy
<Bob> scribenick: Sreed
<DaveS> Note to chair: Bob I will need to go mobile about half way through the call, but will stay on as long as I have connectivity.
Bob: Posted agend is it
acceptable
... Any objects in accepting the Minutes of 7th July
Gil: Non functional reqs specific to 6401
<gpilz> D. Support Migration It should facilitate a migration path of eliminating the offending outbound operations in existing web service implementations.
Bob: Migration with no functional take-aways; improvements & changes are permissible
gpliz: speicifc to as how the
notifications would look like, a particular of construction of WS
Eventing
... Other implementations related to migration
Bob: Particular to older specs what is the point in the migration path
Li: Migration web services WSDL out
bound operations 6401 is trying to develop solution for out bound
operations WS Eventing will propose solution
... If these web services spec is this current will allow to
migrate specific to out bound operations
Bob: Are you suggesting existing implementations migrated without code change
Li: Web services specification from
other standard - in these WSDL the out bound operations. These WSDL
specs to be BP compliant
... Migrate from un-compatible state to compatilble state
Dug: Previous F2F discussed in migration doc need to address this
Bob: Other specs will not be BP compliant?
Wu: it should be relatively to change the BP compliance as required
<dug> what's the point of this discussion? we're all agreed it not going into the spec so what are we arguing about?
<dug> each company will figure out how much of a migration process there is for each feature - vote (make proposals) appropriately
gpilz: Alternative proposal
disucssing with the working groups. Reqs should be relatively easy
to migrate
... Migration chosen in particular specs that been discussing using
the WS Eventing
Bob: Migration path information in the document Geoff did this. Why is there further requirement on migration?
Wu: Solution we developed presented other web services vendor to compse with us - particular requirement
Bob: Providing the information (paragraph) related to this
Wu: Can provide this paragraph
<dug> on firm mud
<scribe> ACTION: Wu will work on information related to the migration (paragraph) [recorded in http://www.w3.org/2009/07/14-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-82 - Will work on information related to the migration (paragraph) [on wu chou - due 2009-07-21].
Geoff: We need Wu & Gpliz to do with the specifications related to this
Bob: New issue Issue-7088
... Need to have the information related to 7088 before the F2F
... We have working document then we can close 7088 - also issues
can be opened to this
... Issue-6720
... http://www.w3.org/Bugs/Public/show_bug.cgi?id=6720
... We had a proposal for the 6720
<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0027.html
Ashok: checking in bugzilla
... Problem was we didnt know exactly second paragraph any document
XML Schema: Structures], [XML Schema: ]
Dug: support transfer
Ashok: will get the XML or policy
Dug: Meta section identifier attribute
Geoff: I don't get what is going on
in this
... Get operation can return many things including multiple
documents interms of Dug was saying it is really not correct
... Get request single representation of the spec any metadata can
return policy, not the get metadata itself
... As what we are arguing in this
Ashok: Original question spec can get all of these things
Geoff: What is actually get is the meta data resource may return any of those - metadata resource many things meta data elements itselt
Dug: Meta you get back could be next
meta data element
... different data comming back so what I wrote is correct
Asir: It is confusing
<dug> Asir you're going too far
Dug: Single meta data unit with particular identifier
<Zakim> asir, you wanted to point out that the term 'dialect' is overloaded in this conversation
Asir: Confusing conversation word dialect
Dug: Using the word dialect - modifying
Asir: particular statement is not
correct
... Why more than one dialect
Dug: One queue name
Asir: I agree metadata queue name it can have children can have more metadata section
Dug: Meta data wrapper
Asir: confusing the terminology
Bob: Asir, could you suggest alternative text?
Ashok: Not completely I didn't now the intent as some clarification required
Asir: It has the variable as wants to return not sure about specific information to put forward
Ashok: One metadata section which can different dialects which we need to spellout this
Asir: I understand & can work out on this
Bob: Asir & Ashok will produce alternative text
<asir> we signed up for clarification text
<scribe> ACTION: Asir & Ashok needs to work on the text [recorded in http://www.w3.org/2009/07/14-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-83 - & Ashok needs to work on the text [on Asir Vedamuthu - due 2009-07-21].
<dug> I'd like 6680 added to the agenda then - sorry I misread the #'s
<dug> 6680 should be a no-brainer
<dug> ie. close w/no action
Bob: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6803
Geoff: Discussion to take place WS
Fragment, some time needs to have discussions what we need to
do
... Is any issue related to this
<Bob> scribenick: Ashok
Bob: Recommended closing 6803 w/o prejudice
RESOLUTION: Issue-6803 closed with no action and without prejudice w/o
Dug: Strictly editorial. Opened by
Gil
... no longer applies. We shd close
Bob: Any objection to close 6680 woth no action
Geoff: I need a minute
... ok no objection to closing
Gil: No objection
RESOLUTION: Issue 6680 closed with no action.
Geoff: We would like option to open a related issue related to or subsequent to 6803
<dug> When the Delivery Format feature is engaged the formatting of the going events occurs after any filtering.
Bob: Yes. That's what I meant by 'close with no prejudice'
Dug: Explains issue
<dug> not Body, its the Event XML
Geoff: Implication is if we only
filter over the content and if we have a header that influences the
body we have a problem
... this is possible
... don't want to rule out something that may be impt for
someone
Dug: We are filtering on event
XML
... if they want to filter on envelope they need a different
mechanism
<Bob> ack [Micro
Wu: This is good if it does not
disrupt existing apps
... we shd double-check apps
<dug> bob - I can answer that
Gil: What is 'raw eveny XML'? Does it include action URIs
Dug: Does not include action URIs
<dug> Actually, ws-e says: Context Node: the SOAP Envelope containing the notification.
Li: Xpath filtering is missing the
context
... what if the msg has multiple parts
Dug: There can only be 1 part
... we may need a separate issue about the the shape of an
event
... filtering has to happen before the binding
Li: If we have 2 parts we don't know which part is bound to body
Bob: Do you need more time?
... 1 weeks?
<dug> +1 to gil
Gil: The issue that Li just raised is
related to issue 6401
... problem is how events are described
... what do you do with a wrapped notification
... my proposal for 6401 and Dug's proposal for this issue meshes
very well
Tom: I need a usecase why anyone would filetr on anything other than the first child
<Tom_Rutt> ws bp requirments (both for rpc/lit and doc/lit) allow only one child of soap:body. I see no reason to filter on anything other than first child of soap body
Bob: I don't hear a lot of disagreement but folks seems to want a bit more time. Let's revisit next week
<li> one man's trash is another's gold
Bob: Proposes we deal with 6980 and then 6692a
Dug: Could we get a concrete proposal for 6692a?
Geoff: You have talked abt 4 issues.
<dug> LOL Geoff - you're a dreamer
Geoff: I am working on d.
a, b, c could be dealt with as separate issues
<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0015.html
Bob: That's a good idea!
<gpilz> bring me the blue pages!
Bob: We will await proposal
Dug: CNA?
No objections heard
RESOLUTION: 6421 closed with no action
Adjourned