raw minutes from 2002-06-10 afternoon

[text for options a and b is missing. hopefully it will be in the
morning minutes]

Jonathan: [summarizing]
 3 votes for a, 11 votes for b

option c
 extension namespace="uri"
 b + top=level declaration of extension namespaces

you declared all extensions, even if they're ignored. if you see one
that it is not declared, you catch-fire-and-die.

Jonathan: I expect that a document that has WSDL+xmlns+soap will work
and will be interoperable.

question: do we want to allow tools to put in stuffs from their own
namespace without having that this is a WSDL file?

Sanjiva: is it a fixed structure or not?

David: do you have to declare up front your namespace?

Sanjiva: yes, equivalent to variable declaration in programming
languages.

Jonathan: except that you can't ignore variables in programming
languages if it is used.

David: and in PL, it will be an error to not predeclare.

Arthur: you will need this predeclaration anyway. for schema location
for example? if a WSDL processor tried to validate the document, it
would need the schema location for the elements declared in the new
namespace therefore, in practice you need either an <import> element or
a schemaLocation attribute to declare the extension namespace. the only
other benefit of having an <extension> element would be to specify
attributes of the extension, e.g. that the processor must understand it

David: in PL, the purposes are the type [N/A in our case], and human
errors.

Sanjiva: for the type, you can infer the type by the usage of the
variable. but not applicable in WSDL as well. the point is: I'm looking
WSDL as a language, not only as an XML document.

Martin: would seem bizarre to declare the xmlns namespace in WSDL in
extensions. not sure why xmlns is different from any user
namespace. seems odd to declare your intent in front

[Sanjiva agreed]

Arthur: doesn't WSDL require required on each element?

[yes]

Glenn: to declare a namespace as required, I would come up with the
extension element, but you can escape some using the required attribute.

Martin: if it's not WSDL required, you have to understand it. that's in
the spec today. all extensions elements are magic for WSDL
anyway. whoever write the extension will define how it behaves.  exactly
like having a soap mustUnderstand in the header, yes.

Arthur: that means, how do you know that it is required if you don't
understand the element

Glenn: use the required attribute in that case. it is up to you to
define if something is required in your namespace.

Martin: seem reasonable to adopt a similar extensibility than the one
defined in SOAP

Glenn: if you say, you have to understand that namespace, that's similar
to say you must understand all elements in that namespace.

Arthur: no [...]

Glenn: if you drop one more element in your namespace, you don't
necessarily want to make it required.

Jack: one extension element can be required in one place, and not
required in an other one.

Roberto: there is a natural expectation that you might want to require
all elements in a namespace.

Glenn: but we have cases when you don't necessarily want to do that.

Sanjiva: no need to spend time on that, it is useful but not a required
feature.

Roberto: we still gain the scoping.

Glenn: yes, different cases that in soap. the exact for saying is
required, and the one to say a namespace [all element in the groups] is
required, the syntax is similar.

Jonathan: we need a statement that says there is some kind of scoping
[hierarchy] and you don't have to process the entire hierarchy to use
the
WSDL. if I put WSDL:required on an element, do you make all children
required as well? the hierarchy of WSDL is <> between the syntax and the
abstract model. do we work as at the abstract level or not?

Glenn: if you process a particular piece of XML, you agreed to do all
required children elements

Jack: for example in the HTTP binding case, we decide we don't care
about the required if we don't know HTTP, you would do, you will have to
deal with it.

free to other specs to say what is required or not.

Glenn: yes, we only deal with WSDL here.

Sanjiva: "all top-level elements has to allow the required
attribute". what about inside?

Glenn: up to them.

Jack: if you process the parent, the HTTP extension (for example) will
have to tell you what do with them.

Sanjiva: if you have 2 bindings, one you understand, one you're not, we
should not die. that's not user friendly.

[Glenn and Jack agreed]

<WSDL:*>
 <my:foo WSDL:required='true'>
   <my:foo required='true'/>
 </my:foo>
</WSDL:*>

Glenn: at the first foo, that's our domain.

Jonathan: we need to define a block then

Jack: I don't think a binding without one operation, but we can process
one operation, without process the binding.

Glenn: I don't think we can remove the required, but we can discuss on
its scoping.

a block is an element in the WSDL namespace.

if there is a child in it, you must understand it, even it doesn't
belong to the WSDL namespace.

Sanjiva: scenario:

I have 2 bindings, one is java, one is soap.  if you understand the
java, you will have to understand fully.  but I don't want to die if
not.

Keith: the processor will realize that you don't have to die.

Glenn: in your case, it won't look at the java bindings, this binding is
not marked as required.

David: no, because the java binding is not relevant.

Glenn: but if you do, you must die if you don't understand something
inside.

Roberto: portType example is a better example.

Keith: then if the portType is required, you fail.

Sanjiva: then the use of required depends on the context?

Keith: no, depending on if your processor is able to understand the
binding or not.

Glenn: if it is able to understand the 2 bindings, you can switch to one
of them if the other failed.

Glenn:if you process a given portion of the document and see
required=true, you must comply to the extension, or failed.

David: one one hand, you want to be able to say, this portion is not
relevant, even if it contains required.  on the other hand, how the
portion is? the required element might not be relevant to the
application.

Glenn: yes, and once you are in this element, it's up to your spec to
know how to deal with it.

Jonathan: then we describe the required semantic when it appears as a
child of a WSDL element.

Roberto: and if you're in a portType?

Glenn: if you put a WSDL portType in your extension, you have to agree
with the semantic of the WSDL portType.

ACTION Glenn: to come up with a proposal by tomorrow's morning.

Jonathan: sounds like we have some agreement of the first 3 points:
 <extension namespace="uri"/>
 - elements and attributes from that namespace can occur in the doc
 - the "specification" of that extension namespace indicate the rules of
 what's required and what's optional
 - not allowed to change semantics of WSDL 1.2 stuff

Jonathan: is it possible to me to write an extension namespace that does
not allow required?

Martin: in soap, yes, it's up to the author to allow the required.

Jonathan: so catch-fire-and-die but only if you need to make use of it./

- changing semantics of WSDL?

Jonathan: if we want to preclude that, how should we describe it?

David: enforcement is a different issue.

David: it's good to define what it means to be conform with the spec.

David: for that reason, we should prevent changing the semantic. if you
decide not to be conform, you're on your own.

Jonathan: and if you extend a port?

Sanjiva: we don't have a use case to redefine port in an other namespace

Keith: any precedent to preclude changing the semantic?

Jonathan: at least in XSL.

Sanjiva: I would prefer to recommend people not to changing it.

should it be possible to override the semantic of WSDL elements?

Keith: examples: you put an extension element on portType, saying all
binding for this portType must in the soap namespace.

second example: operations can allow more than one output.

Sanjiva: my attribute is a key to a schema type, that would a change.

options:

- not allowed to change behaviors of elements.
- we don't say anything.

proposal: "extensions are not allowed to change the semantics of WSDL
elements"

steveT: if you add an element in a portType, are you changing the
semantic?

SteveG: how about "existing semantic"

proposal: "extensions are not allowed to change the existing semantics
of WSDL elements"

8 in favor.

proposal: "you are allowed to change the existing semantic of WSDL
elements"

7 for
7 against

David: "you shouldn't change..."?

Glenn: if someone does this, you can say they are not compliant with the
spec.

Jonathan: status quo: no change?

David: what about my compromise?

Jack: it allows it then...

David: i revoke my suggestion.

RESOLUTION: we won't do anything.

Jeff Mischkinsky is objecting.


JeffM: thinks it is dangerous to allow changing in the semantic.

Jonathan: not our job to define interoperability of extensions.

JeffM: I think it is. it's whether you can call your product "WSDL" or
not.

[subject is moved to tomorrow, pending action item from Glenn]

Martin: that's the problem. tying down the language that says 'you can't
change what we meant!' is pretty hard

[break]

-------------

[jack's presentation]

Abstract Model:
http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0153.html 

Jack: abstract model: simple concise definition of WSDL.  no need to
show the big picture (how's WSDL fit into the architecture, ...).  when
you read WSDL, you create your own model in your head. and of course
they differ.  the amtf had lots of discussions on what is/was the
abstract model of WSDL.  we have design and syntax issues with WSDL 1.1.
for syntax, the AM will not help us. with design, the AM will. would
help identify the issues, different between the spec and the abstract
model.  having the AM will put emphasis on our issues.  one option is,
take the AM and make a syntax for it.  we will end up with something
quite close to WSDL 1.1.  WSDL will not contain unnecessary features,
only the ones listed in the AM.  then we can throw away the AM and make
a part of the spec. but we would be able to point people to it. the
abstract model should be a shared mental model of WSDL. the AM can be
described in UML. both, english and uml, are good.  the AM should be
formal anyway

Sanjiva: if AM is english, then let's put it in the spec then.

Glenn: yes, why the spec does not describe the AM already?

Jean-Jacques: soap am was used as a tool, it has been useful.

Sanjiva: just saying, if jack's description is better than the one in
the spec, let's put it in the spec then.

Martin: the XML schema am is defined in terms of components. and then
there is a mapping between component model and the syntax. the WSDL
constructs are similar to the one we have in schema. when I look at
Jack's message, I see a glossary.

Sanjiva: if WSDL 1.2 was defined in terms in Infoset, what would be the
difference?

Martin: this doesn't give the relation between the information items,
unlike the schema spec. message have properties, parts, parts have
properties as well, ...

Jonathan: so we can rename to components and then define the properties
in it. then it becomes a comprehensive list of components in WSDL

Jonathan: it would be a section of our document

Martin: let's stick in the document for now, and remove it later if we
want.

Jack: then how do we use it? should we start with this and deduce it
later?

Jonathan: each element/attribute will be linked to the abstract
components

Martin: <import> would be irrelevant in the abstract components

RESOLUTION: this work will not be part of the June draft.

candidate recommendation is scheduled for December 2002

Martin: I should be able to provide something by the middle of july

Sanjiva: I have a problem to produce with AM from WSDL 1.1, describe
WSDL 1.2 and then patch the AM since it was produce on WSDL 1.1

Jack: one we have the am, it is a completely new text.

Sanjiva: but still based on WSDL 1.1 ....

Jack: we just want to clarify and fix holes in WSDL 1.1

jeffrey: let's see martin's proposal first.

Jonathan: what should we do regarding the amtf? I would prefer to
address issues within the WG.

RESOLUTION: amtf is no longer.

ACTION: Martin to provide component descriptions for July 12.
[in time for July 20 teleconf]

-----

Infoset

Sanjiva: if we go with the components, we don't need one.

Jack: we still need one, we don't have to deal with different

Martin: do you describe the transfer in different or in terms of
Infoset?

Jonathan: seems that the right answer is Infoset

Martin: yes, will put it along with my descriptions.

Jack: 2 different parts.

Martin: but we need to link them. trying to link my descriptions to the
current spec would be hard.

jeffrey: the requirement is "we need to use the Infoset". and then
Jean-Jacques
put something and that was questioned.

Jonathan: the basic issue is term like elements is ambiguous. should use
element information item.

Jack: but you need angle brackets to transfer an Infoset.

Jonathan: we're talking sending XML, right?

Martin: had this discussion at the XMLP f2f. problem with the soap, it
wasn't clear what you had to write and repeated itself a lot.

Martin: it is hard to write ambiguous things in terms of Infoset.

Jonathan: Infoset is a glossary of terms that can be used to write
specs.

Sanjiva: to be concrete: you say, a message has this property and is
required, ...

[yes]

example:
http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0233.html

Jonathan: proposal is:
martin is going to work in terms of the Infoset and Sanjiva is going to
write the spec in terms of Infoset as well.

Glenn: did we have negative feedback on the use of the Infoset in soap?

Martin: one, and we had several supports for its use. I was tempted to
point people to the schema directly

Jonathan: if we're using Jean-Jacques's prose, it doesn't save a little
much.

RESOLUTION: Infoset? yes.

Jonathan: then I can take a DOM tree and says it is a WSDL file.

Jack: yes

Philippe: do we define how to obtain the Infoset?

Jonathan: no but we can define the processing model in a conformance
section. is XInclude part of the extensions or a required part for WSDL
processor? we can put if WSDL required='true'

Philippe: should we put WSDL, xmlns, XML namespaces required by WSDL
processor?

RESOLUTION: XInclude is part of the extensions.

RESOLUTION: WSDL, and xmlns is required

should we require XML namespace support?

import and XInclude don't have the same semantic.

Martin: based on the schema, you can see that XInclude is an
extension. we can't say to people: we ruled out XInclude. we have an
open content model.

Jonathan: do we require schema processing for default attributes.

Martin: soap does not, I strongly suggest NOT to have default attributes
in WSDL

the question: should WSDL processors be required to support XInclude?

Jack: requiring (or not?) XInclude does not have interop problems.

should we stay silent about XInclude?

RESOLUTION: let's stay at the Infoset level.

[previous issue is closed]

----

Spec title

http://lists.w3.org/Archives/Public/www-ws-desc/2002May/att-0144/02-part1.html

[straw poll]
Web Services or Web Service?
12 for the s, 2 without

[WSDL 1.1 has a typo between the html title, and the document title :)]

"Web Services Description Language (WSDL), version 1.2"

namespace name? [http://www.w3.org/1999/10/nsuri]


Martin: schema took month dated until the REC. let's change the
namespaceURI every time we publish

Keith: we have feedback that year/month is very useful.

-> "http://www.w3.org/2002/06/WSDL"

Jean-Jacques: Part 1 Part 2? Bindings?

Jean-Jacques: soap uses part 1 and 2 in the shortname

shortnames:

WSDL
WSDL-soap
WSDL-http
WSDL-mime
WSDL-primer

Jean-Jacques: regarding splitting the spec, I would wait until last
call. the latter we wait, the easier it might be to maintain.

Jonathan: right now, we're going to publish 2 documents.

 WSDL, WSDL-bindings?

Jean-Jacques: SOAP example:
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html

"Web Services Description Language Part 1: Framework"
"Web Services Description Language Part 2: Bindings"
"Web Services Description Language Part 1"
"Web Services Description Language Part 2"
"Web Services Description Language"
"Web Services Description Language Bindings"

RESOLUTION:

"Web Services Description Language (WSDL) Version 1.2"
"Web Services Description Language (WSDL) Version 1.2: Bindings"

wsdl12
wsdl12-bindings

[resolved]

----------

Keith: element naming conventions?

W3C has no policy.

RESOLUTION: camel case

----------

Summary of action items:

 ACTION Glenn: to come up with a proposal by tomorrow's morning.
  *done* ->
http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0052.html

 ACTION: Martin to provide component descriptions for July 12. [1]

Received on Tuesday, 11 June 2002 05:24:38 UTC