<dug> yves - could be done
that way - but there some concern from MSFT folks when we first
worked on that they wanted to be able to detect an unknown
dialect asap and an attribute was easier than going down one
level.

<Yves> dug - what is the
namespace of Dialect attribute then? having a wstr:dialect
element sounds easier as an extension point than adding an
attribute in wst: everytime you want to do such add-on

<dug> well, since we believe
that RT will be fundamental to T's use it makes sense to have
it part of the same namespace

Geoff: Why are we doing it, as of
now there are no issues raised regarding WS-Transfer and WS-RT
complexity.

Dug: WS-RT only makes sense in
presence of WS-Transfer.

<Bob> Dug argues (amongst
other things), that RT reduces the need for transactional
support, since it would reduce collisions

<Bob> Dave: If they were
written together then the inconsistencies would be resolved,
but then ought to be split

<DaveS> 1) Generally
splitting is better.

<DaveS> But:

<DaveS> 2) Consistency is
needed between Tx and RT. Merging will fix these.

<DaveS> 3) Prevention of
rouge extensions that duplicate RT function.

<DaveS> 4) Interaction
semantics between the two capabilities is more transparent.

<DaveS> 5) Encourage wider
uptake of the full capability of Tx + RT.

<DaveS> - Develop together
and the split

<DaveS> - Restrict transfer
as we split them so as to capture semantic interaction,

<Zakim> asir, you wanted to
talk about the history

<Wu> "<DaveS> - Develop
together and the split" - Do you mean "Develop together and
then split"

Asir: -Duplication, overlap,
needs to be handled on case-by-case bases.

<DaveS> yes: Develop the
specs together to clarify semantics, overlap, common issues.
Then split if the result really looks to complex.

<Bob> ac bob

Bob: Against fully merging the
two spec.

<Katy> Adding to Dave's list
above

<Katy> 6) From Editorial and
WG point of consolidating proposals across the 2 specs is far
easier (wrt time and effort) when they are merged

<Yves> is dialect fragment or
conneg?

<dug> http has fragment
support

<Bob> http frags are a user
agent function

<Zakim> asir, you wanted to
respond to Doug

<Zakim> Yves, you wanted to
say is dialect fragment or conneg?

<dug> +1 to yves - transfer
is missing a ton of http features

<asir> +1 to Yves for using
SOAP extensions

<asir> that is what Resource
Transfer does today

Katy: IBM has implementation of
WS-RT.

<Geoff> +1 to dug for RT not
being as mature at T

<dug> bob - I was referring
to the http range headers not the user-agent stuff

<Katy> My comment was: we
were reluctant to implement rt due to bp compliance issues with
the wst base spec

Daves: Obligation of smooth
transpiration for present implementation.

<Yves> if it is a fragment,
should it be part of the EPR?

Bob: Important consideration

1 - Common stuff should be commonly
defined.

2- RT Fragments, is an extension; is it a
common operation; is it a optional operation.

3- Some RT Features have questions, problems,
unclear, broken

<Geoff> is the value of doing
this work, greater than the amount of work required to achieve
it?

<trackbot> Created ACTION-39
- Produce a document on frag support as an extension. [on Katy
Warr - due 2009-03-18].

<fmaciel> ok

<Bob> we are re-starting

<asir> I promised to add my
statements on 6413 to the IRC

<asir> here it is

<asir> If there are any
overlap between T and RT, those should be identified as
separate issues and resolved

<asir> If there are any
duplication between T and RT, those should be identified as
separate issues and resolved

<asir> If there are any
inconsitencies between T and RT, those should eb identified as
separate isseus and resolved

<asir> if any of the current
RT issues apply to Transfer, the WG will address them across
specs

<asir> We acknowledge the 2
possible cases - simple use case and non-simple use case. We
have seen umpteen impls of the simple use case and we have
plenty of interop evidence. We do not not seen any
implementations of the non-simple use case.

<asir> If any of the RT
issues (filed by Microsoft) apply to Transfer then the WG would
consider that and address it as well. This is similar to how
the WG processed 6428 against Eventing whose resolution was
applied to all 5 specifications

<asir> Re bunding specs will
increase market adoption and interop - this is a myth. Market
adopts value not required and optional features. Bundling is
not the solution

<asir> Re WS-Man created a
domain specific fragment transfer - RT was born in 2006. WS-Man
was born in 2002. It is common for a feature to be born in a
domain specific way and then promoted in a generic manner at a
later date

<asir> RT did not carry the
consensus of the authors during its dev and submission (only
IBM and Intel submitted, Microsoft and HP did not).

<asir> There wasn't consensus
to add RT to the charter ...

<asir> RT frag transfer is an
extension of Transfer (from the SOAP Processing Model point of
view)

<asir> In order to not burden
current dependant specs on Transfer we believe that the
extension should be in a separate specification

<Bob> scribe: Katy

Follow up to Tag/Mex RT conversation

Asir: Ashok polinted out may not
get response for tag
... from tag
... Bob suggested waiting to last call
... we are concerned about time and following the Tag
discussion
... What we could do is put each issue in bugzilla and consider
proactively addressing each of the issues
... then Bob could take these issues to the tag
... We volunteer to get these issues out and propose draft
resolutions

Ashok: There are 2 issues 1) why
WS use EPRs rather than URIs? What answer should we give?
... 2) We could consider what does a naked HTTP GET on the URI
return?

Gil: Think we should address any
issues at LC and not pre-empt

DaveS: Don't want unecessary
energy spent on this.

Asir: Understood, concerned about
potential blocking issue

Bob: Being prepared is good. I am
hearing mixed discussions regarding how much preemptive work
should be done
... If we use the issue process (this is public and debated and
requires closure before last call).
... These are not proper issues - other ways to approach

DaveS: We can prepare a document
and discuss at next F2F
... I will work with you on this.

Ashok: Issues in a WG are opened
against documents, what would these issues be opened
against

Asir: WS-T (2) and WS-RT (1)

Ashok: What could we say here

Asir: We could say: for 1st
issue: This has been considered by the ws-ra working group and
this is what we have decieded (unified voice)
... for 2 propose: SOAP response pattern binding to HTTP
GET

6595 WS-Eventing Specify behaviour for empty
filters

Gil: described issue
... Dealing with filters that will never evaluate to true -
event sources should try to indicate this

Geoff: As Doug said, we need to
ensure that it is clear that the generation of this fault is
only at subscribe time

Wu: Concerned that the client may
use this to test what the event source supports - interop
issues

Gil: This is for simple
situations where the filter is easily understood

<Bob> It is possible for the
request to contain a filter that will not evaluate to true for
the lifetime of the Subscription. Although this condition
cannot be detected for all dialects, implementers are advised
to check for it when possible and, in response to the Subscribe
request message, OPTIONALLY to a Subscribe request

<Bob> message generate a
wse:EmptyFilter fault.

<dug> It is possible for the
Subscribe request to contain a filter that will not evaluate to
true for the lifetime of the Subscription. Although this
condition might not always be detectable, implementers are
advised to check for it when possible and, in response to a
Subscribe request message, OPTIONALLY, generate a
wse:EmptyFilter fault.

Wu: not sure about 'impls advised
to check for this'

Gil: It is just advice

Wu: But this is not preferred

Li: I recognise that this is a
very annoying situation but it's hard to imagine how
implementations could check this - e.g. xpath

Gil: This is intended for filter
dialects with finite values. Just when it's possible. Impls
could do basic checks
... A key thing is to advise subscribers that an extra fault
could be gen'd when it is clear that there will never be
notification messages

Wu: value of pause and resume is
highlighted in web services roadmap document (item 5)
... We think this is useful. I am sensitive to Geoff's comment
so we could make this an optional feature

Dug: 2 things that should add to
proposal. 1) clarify whether buffering of msgs happens
before/after filtering
... 2) Retain parameter on pause and response. I would prefer
the pause to fail if the request cannot be granted

Geoff: would like time to
consider

<asir> perhaps, in another
specification

Ashok: This is extra
functionality, not fundamental to the core spec

DaveS: If client does not have
pause/resubscribe then can it attain same function by
unsubscribe/subscribe

<Bob> k

Wu: pause/resume is a short hand
so does not break interop (as it's a shorthand for unsub/sub)
but retain message number is not shorthand

6498 Define the fault action URI

6404 Mex dialect

Dug: Mex dialect=group of things
that service should return to client to indicate what's needed
for communication
... but what if the service has metadata that the client might
need (but client doesn't know about)
... At extensibility to enable service to add this 'extra'
metadata stuff
... on top of that add 'all' dialect
... then worry about default

Geoff: Our 'whateverdialect' =
Doug's Mex dialect

<dug> 'whateva' used to mean
"random - even zero"

Geoff: also think that there
should be a just mex dialect
... mex=the mex dialects
... whatever=the mex dialects plus optional extras
... mex=mex defined dialects crucial=mex plus other stuff that
need to talk to service

gpilz: Should rename 'mex'

<gpilz> 'mex' should be
renamed 'defined'

gpilz: Confusion is when a bag of
dialects is named the same as a dialect itself

<gpilz> from smallest to
largest (schema | wsdl | policy | policyAttacment), defined
(set of previous), crucial (defined plus sections requester may
not know about), all (everything available to the provider)

Dug: The 4 dialects in the
metadata spec are fairly arbitrary. Also they can be gotton by
separate requests. So the 'mex' (or 'defined') dialects is not
much use.

<dug> none = mex = the stuff
the services thinks the client needs to talk to it - minimum =
tables in mex

<dug> all (new uri) =
everything under the sun the client is allowed to see - ie.
dialect=*

asir: Interop testing refer to
proposal for 6420 (closed as dup of this one). This proposal
talks about min

Dave: I like the idea that the
service knows what you need to talk to it
... eg if I don't need policy documents - why would I return
them?

<marklittle> Hi Bob

<Bob> Hi

Dug: There's a difference between
returning anything and what's required by the client to
talk

<Bob> ?

<Bob> Katy requests time to
conferr with the mothership

Katy: Concerned about the overlap
of these dialects - the same information may be passed back in
policy and wsdl dialects - a huge amount of data in
duplicate
... Puts great requirements on service and large data
transfer

<Zakim> asir, you wanted to
answer Katy's q

<DaveS> If we had only all
and default (meaning what the service thinks the client needs),
what interop or migration problems does this raise?

Ashok: Not clear where policy
documents should be returned on receipt of policy dialect

Katy: policy and policy
attachment dialact not clearly defined

Asir: Policy references give the
link to the policy documents
... policy dialect is not useful on its own but is useful in a
wider exchange

Dug: concerned that we are
overengineering and will confuse people

<asir> well .. at the
discretion of a provider .. you may or may not return
duplicates

Dug: no longer a for-loop service
needs to interpret

<asir> other specifications
may define these dialects ..

Geoff: Don't let us forget the
key issue - the communication bootstrap 'what do I need to talk
to you'

<asir> but for the standards
that have already sailed and relevant to WS should be specified
in this doc

gpilz: just two different things
1) individual dialacts and 2) bootstrap info

bob: we need to write up and
understand
... few primer words to describe expected usage
... (primer like - might be doesn't need to be in primer)

katy: Issue for describing
dialect uri's

s/uris/uri's

bob: The critical set is what the
provider needs to communicate?

consensus to this.

bob: do we agree that 'all' is
useful?

dug: Use case metadata
browser

ashok: or another non-specified
dialect (e.g. legal)

consensus

bob: is it true that a provider
can provide optimisation?

consensus to this.

bob: Waht about the current 'mex'
which is a subset of all?
... do we need to define this piece called 'mex'?

<asir> that was awesome
Bob!

<dug> none==critical,
all=all, allow for list of dialects

<Bob> Agreement:

<Bob> no dialect ==
everything that the provider considers important with the
ability to optimize

6594

6641 Where we get the XSD

<Ashok> This document is also
available in these non-normative formats: XML, XHTML with
visible change markup, Independent copy of the schema for
schema documents, A schema for built-in datatypes only, in a
separate namespace, and Independent copy of the DTD for schema
documents. See also translations.