See also: IRC log
<Marsh> Updated agenda available: http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0065.html
<scribe> scribe: jacek
minutes accepted
?* 2004-11-11: Anish to propose additions to the test suite for
the purpose of interoperability testing,
due 2005-05-12.
? 2005-03-31: Marsh to take on (or recommend closing) Bijan's AI
to produce a component/property table via XSLT,
due 2005-05-28.
? 2005-04-21: Pauld to craft, publish Common Schema structures
to WG for review for publication as WG Note,
due 2005-05-28.
? 2005-04-21: Hugo to continue to look at IRI style/URI style,
due 2005-05-26. (LC74a)
DONE [.7] 2005-04-22: Umit to write an alternate proposal,
due 2005-05-19 (LC117)
?* 2005-04-22: Amy to provide examples for the advanced section
of the primer. Amy to send them to Kevin and test
materials to Arthur, due 2005-05-19. (LC61c)
DONE [.5] 2005-04-22: Arthur to investigate the Schema Designators and
come back with a proposal, due 2005-05-19. (LC64)
?* 2005-04-22: Amy to investigate a solution, due 2005-05-19
(LC74c)
DONE [.8] 2005-05-05: Umit to writeup a simple proposal to make {safety}
as an extension, due 2005-05-19.
DUE 5-26 2005-05-05: Sanjiva to writeup a proposal for LC71,
due 2005-05-19.
DUE 5-26 2005-05-12: Glen to add scoping example to primer, due ?.
DONE [.3] 2005-05-12: Marsh to ask charlton to send his comments to WSA
except the wsdl11/20 terminology comment, due
2005-05-12.
DONE [.4] 2005-05-12: Marsh to add MEP template as LC128, due
2005/05/12.
Outstanding editorial work:
DONE [.6] 2005-04-21: Hugo to define frag id extensions for
soap:header, http:header, soap:module. (LC80)
? 2005-04-28: Arthur to introduce specialized markup for
components and properties.
DONE 2005-05-12: JJM to incorporate Glen's LC18 suggestion.
? 2005-05-12: Primer editors to remove section 7.1.2 - we don't
define scoping rules for extension elements.
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/4/lc-issues/actions.html
[.3]
http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Ma
y/0076.html
[.4] http://www.w3.org/2002/ws/desc/4/lc-issues/issue.html#LC128
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0041.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0035.html
[.7] http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0062.html
[.8] http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0059.html
discussion of MathML version of the spec (for Z notation)
Marsh: bijan has cancelled his
attendance, otherwise we're final
... put up a revised agenda
<pauld> what's the story on net access?
Marsh: added Arthur's Z notation MathML version here
Arthur: looked into MathML
because it's less objectionable than the current version
requiring font substitution in IE
... a MathML version requires XHTML, displays natively in
Mozilla but IE needs a plugin
... still the stylesheet does browser sniffing which was
originally a problem for Hugo
Marsh: we'll have to wait for Hugo with this
Marsh: umit's issue referred to
the editors (with no objections)
... that's the issue about wsdli:wsdlLocation
... issue about what the purpose of #none is
... unclear about what needs to be fixed
uyalcina: there is no guidance on
how/when to use #none
... we need more illustrative example for the use of #none (or
any other # things here)
Tomj: I agree
kevinl: we might add a special example
uyalcina: I can propose an
example if we agree that's useful
... instead of having big example it's good to have smaller
examples even if the features get reused later
Marsh: anybody objects?
Tomj: it's always good to put more examples to the primer
Marsh: that's our plan then
... giving Umit an action item
<Marsh> ACTION: Umit to provide #none for Primer due: June [recorded in http://www.w3.org/2005/05/19-ws-desc-minutes.html#action01]
Marsh: another email about making description/@name mandatory, let's not add it as an issue
sanjiva: we removed the attribute, right?
Tomj: I liked the attribute, it did no harm and could actually do some good
sanjiva: in 2005/5/10 WD we have no name attribute
Arthur: this will cause a problem
for the component model
... adding the attribute, that is
... because we'd have to have multiple description components
all of a sudden
... still waiting for replies from the commentor
sanjiva: the commentor refers to WSDL 1.1
Marsh: let's not add this as an
issue at this moment
... I'll point out to the commenter that we're soon in new LC,
he can re-comment
Marsh: lc121, lc127 finished by
editors, any objections to closing them?
... nope, issues closed
RESOLUTION: LC 121, 127 closed.
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0041.html
Arthur: since element decls and
type defs are components, we should have URI references for
them; maybe we can use schema component designators
... it's not rooted in this situation, the SCD refers to
elements within schema, not to qnames
... we aren't tied to schema
... the proposal is in line with the current syntax for the
other components
... two more pointer parts (with two arguments each), including
URI identifying the type system, assuming other type systems
also have URIs
... we can prefer XML Schema with a shorthand for that
... then there's the description component, I'm proposing a
description() pointer
uyalcina: for the element decls, we'd have both the shorthand and non-shorthand version available together?
Arthur: yes, we'd need both
Marsh: what is the difference between using SCDs and the proposed approach?
Arthur: the fragment syntax is
tied to the media type, ours (wsdl) doesn't include SCDs as
fragments, we'd have to extend ours to include that and still
we'd have to invent the other stuff for the other type
systems
... non-XML type systems are just extensions, can use our
extension fragment syntax for that
uyalcina: I like this approach because SCDs are not widely supported and ours is simpler
Marsh: I thought the whole reason
for this was to have a canonical way for URIs for
components
... now schema has other canonical URIs for the same thing, no
longer being canonical then
Arthur: we have a different thing
than what schema has, different components
... our component model doesn't contain schema components, we
have invented element declaration and type definition, more
general than schema's
Marsh: and this doesn't link to the schema component
Arthur: we only care about the qname, really
Marsh: so the qname is the link, no URIs
Arthur: the short form for XML Schema gives us two ways so we'd not have canonical; we could try to handle this with explicit canonical rule
Marsh: do we have problems with commas in the syntax?
sanjiva: we don't have type definitions any more, do we?
Arthur: property components use them, they were brought back
a bit of discussion on interplay of different schema languages and the type definitions
all is OK
JacekK: could we drop the long way for XML Schema? we wouldn't have problems with canonicalization
Arthur: we could drop it but wouldn't help char-for-char canonicalization
Marsh: amendment: the URI is optional, omited for XML Schema, included for others, can the optional parameter be second?
Arthur: I'm fine with that
Marsh: must make sure that when we talk to XML Schema WG we can tell them we cannot use SCDs because we don't share their components
<uyalcina> +1
Marsh: so two amendments: URI
parameter second, not there for XML schema
... any questions on description()?
Arthur: for completeness
JacekK: we don't need to refer to this particular component
Arthur: goes back to discussion
whether we need this top-level component
... for consistency I'd like to have a fragment for it
... or drop the top-level component
JacekK: we need a URI for the component, not a fragment
uyalcina: same, we could reuse the target namespace for this
Marsh: is there any harm with having this fragment for this component?
alewis: is this a pointer to the
whole thing (component model) or just the single
component?
... any issues about includes etc?
Arthur: at this level we don't
have includes etc.
... and the pointer goes to the component
Marsh: any objections to
accepting Arthur's proposal with the two amendments?
... nope, issue lc64 closed
RESOLUTION: LC64 closed.
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0042.html
Arthur: Paul wants to use
different definitions for the same element on different message
references (and potentially faults)
... his proposal is to have multiple types sections
... his proposal is not consistent with the meaning of
schemaLocation
... but for inlined schemas it could work
... the SCD spec can point to a specific file
... so my counterproposal would be to have an extension that
would use SCD for the definitive location of the
definition
... the upshot is that using WSDL's extensibility one could do
it, little impact on our spec
Marsh: so this attribute would
allow you to find a particular version of a schema, how would
it help?
... oh, it would be on the input element
Arthur: or wherever you have an element="..." attribute for this functionality
Marsh: SCD is not on namespace?
Arthur: one can have an absolute pointer to a particular schema document
uyalcina: I'm fine with Arthur's
proposal, would Paul ask us to bles this particular
extension?
... I'd be uncomfortable with that
Arthur: we could still handle it as an extension, though
JacekK: would there be any impact on our spec?
Arthur: this is an existence
proof that the solution exists
... we could put it in part 2 if he makes a strong case for
it
<sanjiva> I'd be -1 for putting this extension into our wsdlx namespace; I don't see it as a widely used feature at all.
Marsh: would the extension survive our CR process?
<sanjiva> Its not going to be implemented in the Apache stuff for sure :)
uyalcina: probably not
Marsh: we could say: we have
existence proof but little confidence that it would be
implemented
... any implementors would tackle this?
silence and one no
Marsh: close the issue with no
action, communicate the results of the discussion back? Any
objections?
... LC90 closed as just outlined
RESOLUTION: LC90 closed.
Marsh: this issue has already
been closed, but we had some more traffic coming from the
resolution
... on component designators for our binding extensions
... proposal to provide designators for the extensions using
our already existing syntax
... do we want to wait on this? It's already closed...
... seems like an editorial detail on Hugo's part, will
continue to track this
uyalcina: proposal to move the
property to an extension
... removed from core, moved to an extension, we need a
namespace for "well defined extensions", created one, put there
the boolean attribute, in part 2
dorchard: I'm against the
proposal, concerned about companies not implementing the
predefined extensions, it slips through the cracks and people
effectively don't get this functionality; I think it's
important in the core of the spec
... I proposed a different solution, we never did that
... safety is one of the most important tenets of the web
architecture; therefore it should not be moved
<Arthur> +1
JacekK: is the invented URI for "well defined extensions" special for safety or more general?
uyalcina: we need a namespace to
group the extensions we define
... my other proposals reuse the namespace
Marsh: we need not talk about this, we have one namespace on the table now
JacekK: please note this if the namespace gets reused later by other proposals
pauld: echoing a lot what daveo
already said
... it's important for us that safety is core to WSDL
... safety is one of the key properties, simplifications of
WSDL keep that, few other things
... so the social expectations about this would make it much
less available if it was an extension
Marsh: the original comment was about the tooling not being able to guess safety, thus leaving it false
pauld: but .net can add safety as code annotation
<Zakim> alewis, you wanted to ask about semantics
pauld: would have people thinking about this
<kendall> +1 to alewis's point
alewis: I didn't think safety
meant cacheability, for example getCurrentTime is safe but not
cacheable
... so using safety you are not establishing cacheability
Arthur: my understanding of
safety is "you can use get"
... the spec says it more generally
<pauld> just enabling using GET as opposed to always having to use POST would be of great value
Arthur: what we really need is a
way to say "you can use get", because that's usually cacheable,
99% ops are retrieval ops
... agree with pauld that if tooling is the problem with the
safety property, it's not much of a burden to add the
annotation to the code
dorchard: the tooling argument
has two ways of looking at it: platforms have various
annotations and safety annotation is easy to do
... saying it doesn't exist doesn't hold that much water with
me
<Marsh> Safety "defined": http://www.w3.org/TR/2003/WD-webarch-20031209/#safe-interaction
dorchard: but if we're generating
the interface from class descriptions, we don't have that
annotation
... but with the "WSDL-first" style safety can be put there and
would be important
... agree with Arthur that "gettability" is well above the
80/20 threshold; I'd be interested in trying to achieve this
kind of functionality
<Arthur> see: HTTP GET is safe; i.e., agents do not incur obligations by following links.
<Arthur> http://www.w3.org/2001/tag/doc/whenToUseGet.html
<dorchard> jacekK, I agree Put can be idempotent. But the 99/20 point for the Web & Web services is GET/POST...
<pauld> the results of not making a GET 'safe' is a topical subject with the Google web acceleration inadvertently triggering side effects. without the safe tag, you have to assume that ever operation launches the nukes
<Arthur> Use GET if:
<Arthur> The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).
uyalcina: if it's an extension, it calls attention to the use of the attribute; as opposed to the core handling of default (cannot assume safety)
Arthur: maybe we should point to
a better URI for explaining safety
... maybe the wording the WebArch document is not all that
clear without the rest of the document using it in many places
and thus clarifying
... so maybe we should point to both the available good
docs
Roberto: I'm perplexed by safety
at the abstract level
... it makes sense to mark op to be safe on the actual
endpoint
... after considering bindings, policies, implementations
etc.
... but the stuff between the abstract interface and the actual
service can affect whether the safety assertion can be
trusted
<pauld> would prefer the method GET/PUT/POST/DELETE to be exposed
dorchard: I'd be in favor of binding safety more directly to GET
Marsh: dorchard will create a
proposal, we can use chad
... we'll prolly have to do it in the f2f
<Marsh> ACTION: DaveO to ressurect option to indicate GET more directly. due, FTF. [recorded in http://www.w3.org/2005/05/19-ws-desc-minutes.html#action02]
JacekK: responding to roberto, it's about semantics on operations, they aren't only about schemas for messages but also about more semantics in the contract
kevinl: the primer has an example for safety, but that's not enough there, we also need URI style etc, so safety seems a bit small
<Arthur> safety should be a property of the interface since mulitple endpoints are alternates and it would be odd to have one alternate safe and one unsafe
Roberto: the users don't care about separating the abstract contract from the policy etc, it's one interaction
<uyalcina> -1 to Arthur
<Arthur> soap abstracts safety from http by have a webmethod which gets bound to the appropriate verb for http
Marsh: we'll close the discussion
now
... I'd like to point out a few more issues we might want to
get prepared for before the f2f
... not sure the async tf is going to bear on this
Marsh: anybody has a
proposal?
... glen, is the async tf bear on this issue?
GlenD: yes
... async tf is going to recommend a way to do that (support
one-way mep in SOAP 1.2 in WSDL 2), we'll have a
recommendation
Marsh: will it result in WSDL changes?
GlenD: not certain, doubtful, the extensibility hooks should be sufficient
Marsh: will hook this on async
tf
... lc102 is directly related to async tf, right?
... the TF recommendations should allow us to close the issues
quickly
... LC101, mixing binding on ins and outs?
kevin, glen: also related to async tf
Marsh: it seems outside what the
TF is working on
... we need a proposal by f2f close if it's going to affect
us
... is there interest in WSDL-only solution (non-Addressing
dependent)?
... any volunteers?
kevin: we'll see how they in the ATF do, we don't seem to need a WSDL-only solution
Marsh: ok, we'll wait for the
ATF's progress
... we have 17 issues now, we could actually make it 8-)
meeting adjourned