Web Services Resource Access Working Group Teleconference -- 31 Mar 2009

<trackbot> Date: 31 March 2009

<dug> Gil - I just +1'd your idea for Mode attribute - I think that's a good compromise.

<Bob> zakim ??P14 is katy

<asir> Scribe: Asir S Vedamuthu

<asir> ScribeNick:asir

<Bob> Roll 15 folks on the call

dialing back in

pressed the wrong button

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0130.html

Opening

Resolution: unanimously approved the minute from March 24th

Minutes are at http://www.w3.org/2002/ws/ra/9/03/2009-03-24.html

Bob: describing the * | # | X notation

Acceptance of New Issues

Bob - can you type the list?

<Bob> New issue 6739

6739 accepted

Assigned to Dug

Infoset issues - WG wanted to review infoset notation for all specs prioring to adoption

Bob: looking for owners

<li> ping

<Ram> ping

<Bob> pong

<DaveS> ping

<fmaciel> ping

<Bob> scribenick: Gil

<gpilz> Scribe: gpilz

<asir> am back

<asir> let me dump the missing buffer

<asir> <asir> Bob: looking for owners

<asir> <asir> No owners ... these issues are in the "wanted drivers" lot

<asir> <asir> Resolution: accepted issue 6739

<asir> <asir> Topic: New Snapshots and WD time?

<asir> <asir> Bob: time to create a snapshot

<asir> <asir> Bob: Yves is not on the call. Editors do not touch the drafts

<Bob> scribenick: gpilz

<asir> <asir> Bob: plans to create a snapshot

<asir> <asir> ... goal is review the incorporation of resolved issues

<asir> <asir> q+

<asir> <asir> s/is review/is to review/

<asir> <asir> ... send your review comments to the WG mailing list

6730

aisr: will diffs be provided as part of the snapshots?

dug: I can tag the CVS tree, Yves could produce diffs

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730

<dug> create a tag called "WD-2008-03-31"

dave: at the time this was written this redundant text may have been necessary
...: but, at this time, everyone knows how this works

ram: spec has to define what base behavior is
...: extensibility behavior should be defined

ashok: are we asking to remove all occurences of this text?

dave: remove it in all places

<asir> cant hear Katy

katy: if we are going to have this extensibility behavior specified, do we need to have it restated over and over?
...: seems to make more sense just to state it once

dug: I see Dave's point; even saying it once is redundant
...: we've already defined how extenisbility points must work across all specs
... why is WS-Transfer special?

Bob: is it true that none of the other specs have this language?

dug: yes

katy: don't want to do this unless it is specified across all specs

asir: this outlines how to extend the transfer operations using the SOAP processing model
...: we may need to refactor

Bob: how strong is your objection?

asir: I don't understand why we are removing this

<asir> repetition should be refactored

DaveS: the offensive text is repeating stuff that is already specified in the SOAP processing model

<asir> am not aware of anything hidden
...: readers may wonder why we are re-stating this? is there some special wierdness that they are missing?

<asir> the important aspects are - use SOAP Processing Model and MUST NOT change teh base behavior
...: it is worse than just being rendundant
... it is phrased slightly differently, which is bound to create confusion
... and possibly interoperability problems

<asir> Circumvention is not the intent

<dug> +1 to dave - it will confuse people - they'll wonder why we're repeating it - usually that's because something is different and that's not the case.
...: may lead readers to the belief that WS-T is circumventing normal SOAP processing rules

Bob: in the legal world, if you restate something that is already stated, you do so to draw attention to a special distinction

Ram: (agrees that there is a sense of redundancy and some repitition)
...: perhaps we could re-factor?

<dug> we already have an extensibility section

<dug> section 2.4 of WST already has this info

<dug> http://www.w3.org/2002/ws/ra/edcopies/wst.html#extensions

<asir> not all

<asir> That section does not capture all bits

Doug: we talked about this on last weeks phone call - we added a section on extensibility to all the specs

DaveS: we need to outline where the extensibility points are
...: but there is already a section on extensibility (added last week)

Bob: we already have sections on extensibility in every spec
...: given that, how do people feel?

Ashok: I'm ok with it

asir: what is going to be removed?

DaveS: the exact text that is quoted

asir: I'm not sure about that

Ashok: he has the exact paragraph that he intends to take out

asir: I think there might be one or two words that are differnt in each paragraph

DaveS: you can clearly see which paragraphs are copies

dug: speaking as an editor, it is really obvious

asir: it is not the same text, so I don't know

dug: I'm pretty sure the editors can figure it out

Bob: so where do we stand?

asir: I propose that Dave provide us a detailed list of which paragraphs will be dropped

DaveS: have that by the end of the call

6499

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6499

dug: define an action URI for WS-Enum specifically
...: WS-Enum is the only section that inlines fault definitions
... move these to a common section like all other specs

Bob: any questions?

Ashok: This would bring all 5 specs inline?

dug: w/respect to how faults are defined, yes

Ashok: excellent

<asir> vow!

<dug> and they rejoiced!

Bob: any objections to accepting

resolved: proposal to 6499 accepted by UC

6413

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6413

Bob: I need to make sure that the text for all our proposals need to be on the W3C website
...: I've copied the refernced material onto the W3C website

Katy: (go back to March F2F) merge WS-T and WS-RT

<Bob> proposal at http://www.w3.org/2002/ws/ra/9/03/Issue-6413-2009-03-25.html
...: key concern was what would be included etc.
... we took an AI to create a new proposal that just included the base WS-RT support in WS-T
... Doug, Dave, and I worked this and came up with the above proposal
... (describes proposal)

<Katy> This OPTIONAL attribute, when present, indicates the dialect to be used in order to process the child element(s) of the wst:Get and the format of the wst:GetResponse element that is returned. This specification defines a standard dialect in Appendix A. Other dialects may be defined by other specifications.

<Katy> A resource MUST generate a wst:UnsupportedDialectFault if it does not support the specified dialect.

<Katy> When this attribute is not present, child elements of the wst:Get MUST be ignored.

dug: the addition of the dialect attribute on the 4 operations, aside from the fragment support, is a good thing for WS-T
...: a dialect attribute helps to disambiguate some situations that are ambigious in WS-T
... e.g. "actual representation" versus "template constructor"

Bob: comments, reactions?

asir: would like to walk through our objections (posted on email)
... (walks through objections)

<dug> HTTP has no influence on this WG. Neither the charter nor the Transfer specification mentions HTTP at all.

http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0151.html

<dug> please stay within scope of the WG

<Bob> for example this one http://tools.ietf.org/html/draft-dusseault-http-patch-13

Bob: anything that isn't implented by CR will get dropped

asir: these things will end up "at risk"
...: we found that some WS-RT features are unclear, broken, dangerous and harmful

<dug> I don't recall what Asir said
...: we don't recall asking for another proposal

<Bob> Asir, pontification and repetition of history is not necessary
...: this one seems to drop the controversial (???) feature

<Bob> pontification is my relm
...: it seems to add a new processing model based on attribute values instead of the standard SOAP processing model which is based on headers

<dug> but repeating (your own version of) history allows for more time to be wasted
...: looking back at the F2F, it appears to us we need to (a) fix inconsistencies between WS-T and WS-RT
... (b) don't endanger the "sweet spot"
... (c) wider update?
... we need to continue to explore and invent partial updat features that compose well with WS-T
... we need to do this right
... fix isssues
... do not endanger the sweet spot
... do things right

Katy: on the concerns that Asir has raised: these concerns were raised and acknowledged
...: we've gone to great lengths to address them
... the fragment level support is optional and should not impact those that do not wish to support them
... huge parts of WS-RT are not in this proposal; none of the metadata, none of the qnames, none of the (??) dialect (i.e. the simplest dialect is the only one that has been pulled in)
... want to re-emphasize that this is an optional feature

Ashok: Asir, you quoted an IETF draft?

Bob: that was me
...: Asire mentions "PATCH"
... that is a reference to the current draft for PATCH

asir: (history of PATCH) no uptake on this
...: recently it seems like the Atom community would like this feature

<dug> But clearly there is "uptake" for fragment support in the WS* space since wsman and ws-fed use it
...: I provided a lot of references on this

asir: Katy said she addressed all the issues
...: one issue was addressed (the controversial boxcarring)
... a merger is a merger and we don't understand why we need a merger
... it has consequences and impacts other communities and we need to consult with those communities

Bob: we've heard one side w/regards to reservations
...: is there someone willing to speak on the benefits

dug: two aspects
...: (1) the definition of a dialect - generally useful for WS-T
... fragment support is a widely used feature in WS-MAN, etc.
... we need to provide guidance to the community on how to do this or we will end up with lots of different ways
... that would hurt interop
... we want a single solution that is shared across domains
... not domain-sepific solutions

Bob: if, at the end of this process, there isn't the proper number of impls
...: this feature will be marked "at risk"
... this is true regardless of whether these features are part of a separate spec (WS-RT) or in WS-T

DaveS: does the same thing apply to optional features?

Bob: yes
...: even if a feature is optional, we need to prove interop

asir: that's an important point (interop or "at risk")
...: none of the benefits result from merging
... they still have value

<dug> not true - we lose the linking of the features

Bob: are you saying the dialect feature could be added regardless of frag support?

asir: yes, that could be in a separate spec

Wu: I remember during the F2F meeting at Raleigh, this issue was discussed
...: I saw a proposal that I thought was very good - we don't want to merge at this point
... develop each as a separate spec, and see if we want to merge at the end
... the important thing is to develop WS-T and WS-RT

DaveS: value of including frag support in the main spec
...: within the community there are a lot of different approaches to doing fragments at various levels in the stack
... this is about demonstrating leadership
... if we leave this out that leaves the ws community w/out guidance
... the proposal here is very conistent with ws architecture w/respect to identify a resource
... (no reference parameters, etc.)
... demonstrate leadership, uniform frag support, don't worry about implementations (they will come)

asir: leadership is not a function of merging
...: people will take our leadership seriously
... leadership is not a function of merge
..: leadership is not a function of merge

Bob: let's take a straw poll on the essence of the proposal

<asir> Yves is not here to represetn w3c
...: everyone clear?
... "yes" is "in favor of"
... "no" is "not in favor of"

Wu: it is very hard for us to make decisions
...: because we don't know the consequences

Bob: everyone clear?

<asir> Yves is not here to represent W3c

Oracle - yes

Microsoft - no

IBM - yes

Fujitsu - yes

Hitachi - yes

Avaya - abstain

SoftwareAG - yes

Bob: one 'no', a bunch of 'yesses' and one 'need more time'

<asir> Yves is not here
...: Wu, would one week do?

<asir> am very concerned about how we build consensus

Wu: two weeks would be great

Bob: we'll give Avaya two weeks
...: in the meantime, maybe we can move closer to consensus

asir: it's too late
...: I wanted to mentioned that yves is not here
... we don't seem to be building consensus

DaveS: point of order - I've posted an update to our previous issue

Wu: ... I would also hope that IBM and Microsoft could communicate on this issue - that would help us

6730

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730\

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730

DaveS: (describes update)
...: the text to be removed is definitely redundant

Ram: thanks to Dave Snelling
...: it looks fine
... I have one question
... Section 2.4 of the editors copy talks about extension points
... I was wondering if this notion of extension points has been identified in WS-T

DaveS: this issue was solved a couple of calls ago

<dug> xs:any and ... are the extension points
...: all specs call out what their extension points are

Ram: have the extension points for WS-T be described?
...: I'm fine with Section 2.4
... but I'm worried about extension points
... I'd like to look at the proposal and reply by email

Bob: we don't usually decide things by email, would you like more time?

Ram: can we wait a couple of days?

DaveS: it's a simple thing

(other): concur

Bob: I recognize that some folks may need to talk to the mother ship, but this issue has been kicking around a while

Ram: it is generally good to have a concrete proposal a couple of days before the call

DaveS: the original proposal was precise
...: people just called on more precision for this call

asir: can we have a week

Bob: yes, but any more time is going above and beyond

yyi,ms7ik8yhsdkyujuau7jmkyyhjunmyu7jhnm

DaveS: could people actually talk to their product people?
...: because it seems unlikely that anyone asked their product people about the previous incarnation

<Bob> http://www.w3.org/2002/ws/ra/BugzillaReports.html

dug: if people need more detail, they should say so before the concall
...: not wait until the day of the concall to say they need more detail

Bob: people should look at the issues with proposals and be prepared to discuss them
...: it seems that people are capable of using the email list to discuss proposals
... when I don't see any debate, I get the feeling that people are in general agreement

- DRAFT -

Web Services Resource Access Working Group Teleconference

31 Mar 2009

Attendees

Contents

Opening

Acceptance of New Issues

6730

6499

6413

6730

Summary of Action Items

Scribe.perl diagnostic output