See also: IRC log
<trackbot> Date: 31 March 2009
<dug> Gil - I just +1'd your idea for Mode attribute - I think that's a good compromise.
<asir> Scribe: Asir S Vedamuthu
<Bob> Roll 15 folks on the call
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
Bob - can you type the list?
<Bob> New issue 6739
RESOLUTION: New Issue-6739 accepted without objection
Assigned to Dug
Infoset issues - WG wanted to review infoset notation for all specs prioring to adoption
Bob: looking for owners
Bob: looking for owners for issues 6701, 6702, 6703, 6704, the Infoset notation issues other than for Eventing
No owners ... these issues are in the "wanted drivers" lot
Resolution: accepted issue 6739
Bob: time to create a snapshot
... Yves is not on the call. Editors do not touch the drafts
... plans to create a snapshot
... goal is to review the incorporation of resolved issues
... send your review comments to the WG mailing list
<gpilz> Scribe: gpilz
<Bob> scribenick: gpilz
aisr: will diffs be provided as part of the snapshots?
dug: I can tag the CVS tree, Yves could produce diffs
<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
...: 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?
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
...: 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
...: 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 well known, 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
<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
dug: define an action URI for WS-Enum
...: 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
<dug> and they rejoiced!
Bob: any objections to accepting the proposal in bugzilla?
RESOLUTION: proposal to 6499 accepted by UC
Bob: I need to make sure that the
text for all our proposals are 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.
<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
...: we found that some WS-RT features are unclear, broken, dangerous and harmful
<dug> I don't recall what Asir
...: 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 boxcaring feature
<Bob> pontification is my
...: 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
...: Asir mentioned "PATCH"
... that is a reference to the current draft for PATCH
asir: (history of PATCH) no uptake on
...: 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
...: 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
...: 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?
...: 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
...: 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
...: everyone clear?
... "yes" is "in favor of"
... "no" is "not in favor of"
Wu: it is very hard for us to make
...: because we don't know the consequences
Bob: Is everyone clear?
<asir> Yves is not here to represent W3c (Bob notes while editing these minutes that this is only a straw poll)
Oracle - yes
Microsoft - no
IBM - yes
Fujitsu - yes
Hitachi - yes
Avaya - abstain
SoftwareAG - yes
Red Hat - yes added by the cahir at the request of Mark Little since he had a flaky phone
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
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
...: 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
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
...: 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
DaveS: could people actually talk to
their product people?
... because it seems unlikely that anyone asked their product people about the previous incarnation
<Bob> Bugzilla reports page linked from WG home page 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: I made the bugzilla reports page
so that people could see which issues have proposals. Please 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 and many do
... when I don't see any debate, I get the feeling that people are in general agreement. So if there are proposals that you have problems with, discuss them on the list.
... Please look at the irc and if there are any points underscribed or inaccurately scribed, please make entries now while your memories are fresh.