See also: IRC log
<trackbot> Date: 25 January 2011
<scribe> SCRIBE: gpilz
RESOLUTION: agenda agreed to
RESOLUTION: minutes approved
Bob: like to clarify what I'm
thinking about
... typically there are some issues that come up as a result of
implementing, issues that come up as part of testing
... we have participants that will be at the F2F and others on the
phone
... would like to group issue discussions into the morning times,
testing in the afternoons
<asoldano> nice idea
Bob: is that acceptable?
(no comments on phone)
scribe: as far as timings go - is start time of 9:00 ok?
Gil: 9:00 - 5:00 is fine
Bob: group dinner on 2/15?
Gil: I can scout around
... make some recommendations
Ram: Gil, is breakfast or snacks served?
Gil: same deal as all Oracle
conference center events
... they put out food for breakfast and lunch in the hall
Bob: hasn't changed since the
previous call
... we've had a slew of new issues
Gil: maybe we could handle the
simpler issues first?
... these are all post-CR issues?
Bob: if we resolve an issue with a substantive change - we have to go back to Last Call
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11625
Doug: on DeleteMetadata - it doesn't
say what to do if the target metadata doesn't exist
... would like to see it have no effect - silent ignore
... no fault etc.
Gil: could you expand?
Doug: if someone wants something
deleted and it is already deleted (or just not there) - they have
the intended result
... why bother them with a fault?
Gil: feeling uneasy about this - the client has no idea that what they thought was true isn't
Doug: they could always check if it mattered that much to them
Bob: we've been here before - MEX doesn't support any kind of transactionality
Katy: we've decided this before - the
Delete should just fail silently
... what would you do if you got a fault anyway?
Bob: any objections to accepting as a new issue
(none)
Bob: any objections to accpeting proposal for silent fail?
Gil: where's the explicit text?
Bob: in the issue
RESOLUTION: Issue-11625 resolved with proposal in http://www.w3.org/Bugs/Public/show_bug.cgi?id=11625
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11697
Doug: (explains issue)
Bob: I think there is a pre-defined SOAP fault for this
RESOLUTION: Issue-11697 accepted and left open
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11698
Doug: (explains)
... implies that default for @Name is "unwrapped"
Tom: doesn't option (1) require a schema change?
Doug: yes
Tom: I like option (2) better than
Bob: any objection to accepting as a new issue?
(none)
Ram: I don't have a particular comment - I just need more time to consider this
RESOLUTION: Issue-11698 accepted and left open
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11703
Doug: (describes)
... also the issue of what happens if the event source notices the
bad filter later (after SubscribeResponse has been sent and
processed)
Tom: what is difference between that,
and your disk drive going down?
... maybe you should just kill the subscription and send a
SubscriptionEnd
Doug: none, but you need to be explicit about it
Ram: I need more time on this as well
RESOLUTION: Issue-11703 accepted but left open pending further investigation by Ram
Doug: (describes)
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11723
Doug: (proposes adding new fault)
RESOLUTION: Issue-11723 accepted but left open pending further investigation by Ram
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11724
Doug: (describes)
... proposes rewording to make clear that an absent frag has no
effect (fail silent)
Tom: when you say you don't do anything - you don't respond?
Doug: you send back a valid response message - as if the Delete had succeeded
Tom: sounds right to me
RESOLUTION: Issue 11724 accepted but left open pending further investigation by Ram
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11725
Doug: (describes)
... use InvalidInput fault
Gil: (confusing rant about not requiring receiver to validate everything the consumer sends it)
(back and forth about conformance philosophy)
Tom: "MAY" be ok - or qualified MUST
Gil: "... if the service detects {foo} and chooses to fault, it MUST generate the {bar} fault"
<Tom_Rutt> but from a testing point of view, the qualified MUST is no different than the MAY, from te point of view of the client
RESOLUTION: 11725 accepted but left open
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11766
Doug: reword things to make it clear that you don't have to update the resource if you don't support the schema of the thing that was passed in
RESOLUTION: Issue-11766 accepted but left open
Doug: @language is required (tells
you what dialect you are using)
... this is very much like a filter
... @language should be optional and default to XPath
... is this a "substantive" change?
Bob: up to the WG to decide if it is a "breaking" change
Tom: changing something from mandatory doesn't sound like a break
RESOLUTION: Issue-11772 accepted and left open
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11776
Doug: (describes)
RESOLUTION: Issue-11776 accepted but left open pending more investigation by Ram
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11790
Doug: (describes how we screwed up)
simplest example of this is
<mex:MetadataSection @Dialect='wsdl:definitions' ...>
<wsdl:definitions xmlns:wsdl="http://www.w3c....>
Gil: (futher explanation above)
Tom: XPath has a work-around for
this, but we're not using XPath
... baffled
Katy: 'wsdl:definitions' - the "wsdl"
part is shorthand for "http://www.w3...."
... the prefix doesn't matter
I like <mex:Dialect Type="{nsURI}localPart" ...
<dug> Possible serialization options, if we do want to change it:
<dug> - <mex:Dialect Type="nsURI/localPart" ...
<dug> - <mex:Dialect Type="{nsURI}localPart" ...
<dug> - <mex:Dialect TypeNS="nsURI" TypeName="localPart" ...
Tom: if we don't go from changing it from QName we'll have to use @prefixMapping from one of the WSDM-related specs
RESOLUTION: Issue-11790 accepted and left open
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11849
Gil: (describes)
Proposal - replace the first sentence with the following: "This REQUIRED attribute indicates the type and version of the metadata unit contained in this MetadataSection (e.g. WSDL version 1.1)."
previous: This indicates the type and version of the metadata unit contained in this MetadataSection (e.g., WSDL version 1.1).
RESOLUTION: Issue-11849 accepted and resolved with proposed text from: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11849
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11850
Gil: (describes)
RESOLUTION: Issue-11850 accpeted and left open pending further investigation by Ram
<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11865
Katy: I hadn't thought of this as a
problem on the Get
... 2 issues - (a) Get and (b) Put/Delete
... only solution I see is Replace or Delete all the documents
identified by the Dialect/ID tuple
... Get is another matter
Doug: solution in my mind is what
Katy was saying
... Get and Put contain "complete" set of all metadata matching the
Dialect/ID tuple
... interesting twists around @Content
... if I ask for everything that can be referenced via EPRs -
clearly I might not get the "complete set"
... we need something that says "if you have multiple sections for
the same Dialect/ID/Content triplet, they are all separate parts of
'the same thing' and there are no duplicate sections"
<Tom_Rutt> I am confused, if there are several schema file with the same namespace, and that namespace is used as @Identifier, would every root element in that "combinded schema" across the namespace be allowed to be send in the return? what if there is a single global element defintions which is a multiple container?
Doug: currently there is nothing in the spec that prevents you from returning a Metadata document with duplicate MetadataSections that contain the exact same XML
Tom: I'm confused - when you are talking about multiple schemas with the same targetnamespace
RESOLUTION: issue 11850 accepted and left open pending some reasonable proposal
<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11867
Doug: (describes - editorial)
RESOLUTION: Issue-11867 accepted and resolved with proposal in http://www.w3.org/Bugs/Public/show_bug.cgi?id=11867
Bob: text is available for review
... on home page
... need to work on indicating which features are at risk
Li> new CR version - is it stable enough to implement?
Bob: only thing that may change is "status of this document" section
Doug: if these are the docs we are going to be testing against - we need to know what the namespaces will be so we can use those
Bob: depends on the timing of when we
roll out the specs
... you can use the current namespace for the Feb testing
Doug: I'll update the scenario doc to indicate this
http://www.w3.org/2002/ws/ra/edcopies/scenario.html
Bob: I've noticed a few changes going
by
... how are we doing for Feb?
Ram: I think these are fairly stable and implementable
Doug: this doc needs to go through
more changes - more variations
... mainline scenarios are there - but we need to add
variations
... missing critical bits of info
... Eventing and Enum talk about testing *End
... but how will this be triggered?
... need to specify in the doc
Ram: as long as the core scenarios are intact we can do the fine tuning later
Bob: we're going to test, grind
through, find issues (spec, scenarios, test infrastructure)
... will need to take another whack at testing
Ram: can we call "freeze" on what we have in the scenario today?
Bob: plan to test what we have now
Doug: I'm OK with the idea that we
don't have major changes
... not comfortable with the idea that the scenario won't
change
Bob: just want to set expectations
about what people should bring to the table in Feb
... as firm as a marshmallow - but formed
... need to give devs something to shoot at
Doug: people shouldn't be surprised if additional scenarios/cases are added
Ram: I'm ok with that - as long as we have a stable version to shoot for
Bob: we need to declare a date that
defines how long the CR will last (minimum review period)
... can't go to PR before that date
Tom: if we have some of the schema
changes it looks like we might have
... can we progress to PR, even if we change the namespace?
Bob: if we make a "breaking change" (lots of changes are not breaking)
Tom: we can have a new namespace for the PR schema from the CR schema
Bob: you don't necessarily have to change the schema
All: (reviews proposed directions to issues and concludes that we will probably have to change the namespace)
Bob: we may need a 2nd interop
... April 29th end of review period
<dug> 60 days for me
<dug> so march
<Bob> march 31
RESOLUTION: end of CR period March 31st, 2011
<Bob> rrsagent generate minutes