- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 24 Jan 2003 11:43:40 -0800
- To: <www-ws-desc@w3.org>
-------------------------------------------------------
Wednesday 22 January
-------------------------------------------------------
Present:
Erik Ackerman Lexmark
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Youenn Fablet Canon
Martin Gudgin Microsoft
Tom Jordahl Macromedia
Philippe Le Hégaret W3C
Steve Lind AT&T
Kevin Canyang Liu SAP
Michael Mahan Nokia
Jonathan Marsh Chair (Microsoft)
Dale Moberg Cyclone Commerce
Don Mullen Tibco
Arthur Ryman IBM
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates
William Vambenepe Hewlett-Packard
Steven White SeeBeyond
Umit Yalcinalp Oracle
Prasad Yendluri webMethods, Inc.
Observers:
Martin Duerst I18N
David Orchard BEA
Phone:
Amelia Lewis TIBCO
[Yoenn scribes]
-------------------------------------------------------
09:00 Approve publication of WDs.
Jonathan: Objection to publishing part 1 & 2?
(no)
-------------------------------------------------------
09:05 Requirements Document Last Call comments
- Request to address attachments [19]
(IBM\John Ibbotson and IBM\James Snell)
- Comments re: various requirements [20]
(BEA\David Orchard)
- A thorough accessibility review [21]
(chair of the W3C/WAI Protocols and Formats WG [22])
Goal of this session is to dispatch some of the easier ones, while
identifying dependencies among the others (e.g. completion of
Requirements for the SOAP Attachments Feature by the XMLP WG).
[19] http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0081.html
[20] http://lists.w3.org/Archives/Public/public-ws-desc-comments/2003Jan/0000.html
[21] http://lists.w3.org/Archives/Public/public-ws-desc-comments/2002Dec/0002.html
[22] http://www.w3.org/WAI/PF/
Jonathan: 3 sets of req comments.
1 = attachment, but wait for xmlp wg.
2 = DaveO's comments
3 = extensibility reqs
We'll take up DaveO's [20] while we have him.
DaveO: First paragraph about style of reqs.
(discussion about DaveO's reqs)
DaveO: It seems reqs written toward design. Some kind of
generalization might be made. Some examples in my mail.
Example = R118.
Jonathan: Terminology seems too specific.
DaveO: Yes, written toward design. R118 is for reuse of components.
Rephrase as "should allow the reuse of a group of interfaces"
Gudge: We designed a way to reuse interfaces without the serviceType
thing, so you're right.
DaveO: R058 is the same as R118.
Jonathan: No pb rephrasing them.
DaveO: I have some other examples.
Jonathan: Maybe we should ask the editors to point out the ones to
rephrase.
Jonathan: DaveO's comment = not only R058 and R118 have the same problem
ACTION: Jeffrey to rephrase requirements R118, R058, and point out reqs
that seem to specify a design and propose rewording.
Topic: Comment #1
DaveO: Concrete sugestion. The description language SHOULD provide for
validation of WSD documents that are entirely abstract and MUST
not contain non-abstract information and provide for validation
of WSD documents that are entirely concrete and MUST not
contain abstract information. Design to separate concrete and
abstract info. Hard to ensure that wsdl files are abstract or
not.
Gudge: If you refer to the abstract components, no more pb.
DaveO: But if you include a wsdl file, you will also import concrete
components.
Gudge: Why not defining a special "only abstract" import?
DaveO: We can write special wsdl abstract files for choreography.
Gudge: Right, but if someone has written what you want and added
concrete things you should reuse this work. You do not need
"only abstract" wsdl files to do what you want... I can
write a schema only allowing abstract components, it is
technincally doable.
Jonathan: There was a suggestion on the wg to alwyas split the wsdl file
in two (abstract & concrete) files.
Gudge: Tools can always ignore/filter the concrete things...
Umit: It seems like a toolability issue.
DaveO: It is also about reusability of wsdl in other languages like
choreography.
Gudge: A porttype is complete by itself, it does not need binding to
complete its semantic. Our design solves your issue.
DaveO: I feel some pushback...
Tomj: You can always validate the wsdl.
DaveO: You can always enforce some rule with a sub-schema.
(more discussion on validation of abstract wsdl files...)
Gudge: You can have a wsdl files that only contain services elements
or portType elements but I won't help solving your pb.
DaveO: Taking a lookout of wsdl then extract of a subset.
Gudge: Why can't you write a choreography spec that says we only use
the abstract components (portTypes and messages)? The pb is that
the concrete binding in the wsdl file will be superceded by
concrete info from the choreography file.
DaveO: Can you write a schema that only allows abstract components?
Gudge: Yes it is trivial.
DaveO: You can have a full schema and then two separate (abstract &
concrete) schemas as profiles.
Jonathan: We can do that but not sure of the value.
TomJ: Can we move on ?
DaveO: We are not that in a hurry. I can do the separation, I have
done it but it will help people to have this in the spec.
(discussion about uddi)
Arthur: You do not include a wsdl file but a link to it then you
register...
Gudge: With the import mechanism, no way to insure there is no
concrete info even with a schema.
(discussion about reqs that we decide not to do)
Jeffsch: These are still in the doc.
ACTION: Jeffsch to document as a non-requirement.
Topic: Comment #2
DaveO: 2 is about use cases. I try to track what the wsd wg does and
it is difficult to know why some decisions have been made.
Some use cases could help. I 'd like use cases to be written.
Jonathan: No use cases editor around the table. We cannot promise
anything. Lots of decisions are made to solve issues.
Rationale and closing of issues help understanding this.
DaveO: When closing an issue, an illustration would help.
Topic: Comment #3 (no reqs on description of XML based Message content
constraints)
DaveO: Nowhere it is said that you can have a schema that will
validate the message contents.
TomJ: Pb with the data encoding.
JeffSch: And also other schema languages.
DaveO: We can rephrase with syntactic schema languages.
ACTION: JeffSch to add this requirement (suitably worded).
Topic: Comment #4 (The description language definitions MUST describe
constraints upon service locations for http: URIs, and SHOULD
describe constraints for URI schemes in addition to http:.)
JeffSch: For the non soap-http binding, having url scheme (?) For
example a soap-smtp binding?
DaveO: Mix parameters in the url as well as in the soap binding.
We can generalize the http binding url replacement. We
should allow people to describe other bindings than http
at least in the url replacement.
Jonathan: Objection ?
JeffSch: A little bit confused with the first sentence.
(ok adding this req)
ACTION: jeff to add this req
Topic: Comment #5 (The description language message definitions SHOULD
describe constraints on non-XML based message content)
DaveO: You reach this the mime binding. Number 5 is met
TomJ: Constraints of non XML data ?
DaveO: Yes with the mime type attribute.
JeffSch: The req is to produce a normative binding to non XML message?
DaveO: We are not talking of XML. A web service accepting non XML
data should be able to described, at least with the mime type.
Jonathan: On the board, here is an example of a mime:type. Someone can
do it but we are not doing to create normatively such a
language.
DaveO: Is it normative in WSDL1.1 ?
Gudge: Wsdl1.1 is not a standard
DaveO: Then I like my req
Gudge: A binding and a type system are very different. Do you want
a mime binding or a mime type system ?
TomJ: He will take a mime binding.
DaveO: A mime type system also.
(discussion on rephrasing the req)
DaveO: I like this <mime:type> thing.
Gudge: It is a mime type system.
Roberto: We should solve this at least at the binding level.
DaveO: We should also have a way to validate messages.
JeffSch: Abstractly you can define messages with different media
entities. On the wire, you are not sure it will be serialized
as a mime-multipart message. E.g. it can be serialized as
base64.
Gudge: At the abstract layer, you don't know how it will be
serialized. At the abstract level, what do you really want ?
DaveO: I am not sure....
Gudge: If you care about the serialization, we should have some
kind of mime type binding.
ACTION: JeffSch to reword req 5 and DaveO to review it
Topic: Comment #6 (Remove R110 - seems way too specific)
TomJ: Should we wait for William to decide ?
ACTION: Jonathan to add this on our cut list and wait for william.
TOpic: Comment #7 (The description language MUST support message parts
that are in the address and the body. The WSDl 1.1
http:urlReplacement element says that ALL the message parts
are in the URL. But imagine the use case of POSTing a purchase
order. The purchase order ID might be in the URI, whilst the
POST body contains another message part.
Gudge: No technical reason for the soap-http and http bindings not
to do that.
Arthur: Uri usage today does not conform to the arch view.
DaveO: We should allow the modeling to choose between adding the
purchase_id in the url or in the message body. The approach
is to support soap and then add the url:replacement thing.
I think that these things are more coupled.
JeffSch: It seems interesting.
DaveO: This is a web arch suggestion.
Arthur: What about multi-hop messages.
Jonathan: Add this req as a should ?
DaveO: If you do not accept this req, there might be some push-back
from the tag... Why not adding a generic req to allow map
parts into the url ?
Arthur: It is the case in the http binding.
DaveO: But not for the soap binding.
ACTION: jeff to add this reworded req
Topic: Comment #8 (The description language MUST support optional
message parts in the address. I don't see a way of using
http:urlReplacement and having some parts being optional.
DaveO: Need to add optional parts.
Arthur: Parts are not optional at all.
JeffSch: We had an issue about url-replacement. We might want to
reopen this issue.
DaveO: At the moment, every part must be encoded in the url if
using the url replacement.
JeffSch: Tag priority for this req ?
DaveO: Good to have but not essential.
Topic: Comment #9. (The description language SHOULD provide for
description of optional message parts)
JeffSch: Vigorous push back if needed to reinventing xml schemas
things. Discussion in this wg and several proposals.
DaveO: If using xml-schema for message parts, how will you
relate to url replacement ?
JeffSch: It is not any harder.
(discussion on this topic... (one solution is xpath))
Reword: Description loangauge must or should provide for description
of optional content.
TomJ: No must because we may want to keep the status quo.
Umit: And we close the door for ibm's proposal.
Topic: Comment #10 (The description language SHOULD provide a
construct for references to identifiable elements.
Gudge: Is it R120?
Arthur: Is it R085?
Gudge: Even in WSDL1.1 a message can include a wsu:portReference....
DaveO: Yes but we should have this in the spec, in the wsdl ns
Gudge: The wsu thing already exists. Is it that this element is
not standardized?
DaveO: There should be one construct defined by this wg.
Roberto: R120 will do 95% of the work so why add this new req?
DaveO: Suggestion: The description language SHOULD provide a
construct for references to identifiable elements.
JeffSch: Change "desc language" to : "the wg" should provide a c...
ACTION: Jeffsch to propose wording for requirement related to a
portReference construct.
-------------------------------------------------------
10:30 Break
----[Begin Joint Session with Architecture Group]----
-------------------------------------------------------
10:50 Status report for dependent documents (Usage Scenarios,
Glossary, etc.)
Jonathan: Editor's copy are public and wd to be published. Usage
scenarios: no editors here and they are on the floor.
Hugo: Some comments about the doc (arch usage scenario). Need
to go through and decide what to do. No update since
the publication.
Jonathan: Priority is part 1 & 2 but usage scenario is in our charter.
MikeC: A unique arch&ws usage scenario ?
Jonathan: Back out if coordination makes things harder or we can make
the coordination work.
MikeC: We should have a joint document. It is more on the arch side
and the ws wg should just point to this doc
Jonathan: If any update by arch wg, let us know.
MikeC: Revigorate a joint task force?
???: Do the use cases drive things like the 7meps things?
Jonathan: Yes but these use cases are not formally written.
DaveO: Maybe the wsdesc wg should review and update the doc the
arch group made.
Jonathan: Maybe time to reappoint editors ?
DaveO: Maybe somebody should drive us for the reviewing process. Use
cases and reqs are coupled.
[Chair's summary: Will reappoint Useage Scenarios TF members.]
Glossary status
Hugo: No new draft. Some conflicting definitions, missing ones also
We will publish it soon.
MikeC: Capitalization of wEb ServIce ?
Jonathan: Yes, done
-------------------------------------------------------
11:00 Message Exchange Patterns - current state of WSDL.
Jonathan: A word about message exchange pattern. There are three problems
First= soap has the mep mech, wsdl has input output things, how
to relate. Second= outbound operations. Claim that they are not
interoperable. Third= Documenting Inbound operations better. We
have a plan. Don Mullen has an abstract mep framework. We
think the ws-arch should own a template for mep.
???: What about features ?
Jonathan: Ongoing discussion.
Hugo: New features like Ws-security arise.
Jonathan: Cannot use the soap-uri for the wsdl request-response. We will
have new uris. in, in-out, and so on. 123 and 456 are mirrored
ops. Last one is with one out and in msgs from multiple nodes.
DaveH: Document for guidance?
Jonathan: Yes, and we use the feedback from our 7 meps building to refine
the abstract mep template and guidance doc.
(explanations on meps)
-------------------------------------------------------
11:20 I18N Web Services Task Force introduction and overview
(Martin Duerst). First WD of Web Services I18N Usage
Scenarios [23].
[23] http://www.w3.org/TR/2002/WD-ws-i18n-scenarios-20021220.
Topic: internationalization of web services (Martin Duerst)
Martin: Glad to be here
[<dbooth> (The projector fails to work, so Martin starts without it.)]
Martin: (see http://www.w3.org/2003/Talks/0122-duerst-wsdl/)
Talk about the issues we tackle. Started last December. Work
item is usage scenarios. Should be completed before the summer
vacation. At that time we should know the remaining work. Make
sure that WS works worldwide. Few examples between ws and
internationalization. For instance encoded text. Certain web
services may have int. aspects that you might want to describe.
There are also interesting applications of ws to int. The
80-20 rule is not that valid for int. day format web service.
Interesting efficiency issues (caching...). Usage scenarios
doc: Data encoding, language negotiation, language negotiation
for soap faults. Examples of how you might want to transmit
your data. Presentation rules might be local. Best
practice/guidelines to build web services wrt int. aspects.
Content like currency. User interfaces issues. Consistency
across platform issue. Look at extensibiliy mechanims.
Another issue is architectural complexity. Independency of
components is good for us, less work. Sanjiva sent a
proposal which seems to be a kind of abstraction that we might
need. Happy to discuss with you. Please advertize our work
to interested internationalization people in your company.
We are looking to close infrastructure issues.
MarkJones: Int. aspect with the concrete attachment feature work ?
???: Example = attachment with a cartoon in japanese and one in
english
Martin: Language negociation is already present in http. We should
check with dime.
MarkJones: The binding could have a kind of a DNS resolver for parts (?)
Daniel: Concerning ws-arch, we should have a req that allows int.
plus section 2.2.10.
Martin: Maybe some reqs on extensibiliy, composibility.
Daniel: The points you make can generally be directly mapped to the
languages. Most of the issues can be addressed within the
ws-desc wg.
Hugo: Language negotiation can be done at different levels. Have
you discussed which level would be better?
Martin: If you have int. at different levels, you get conflicts.
Difficult to see what will be the core spec (you can have
soap or one other thing). If there is one place where you
have only one place, it would be easy. We have not found
this place yet
Jonathan: Thank you martin
-------------------------------------------------------
Mikec: Time for one more issue ? Talks with oasis security guys
to come up with a wsdl desc of what they are making.
Jonathan: No real comment from the ws-desc for the ws-arch to send
comments to oasis guys.
DaveH: Boundary lines between wsdl and security/policy/ontologies?
what description means ?
Jonathan: Will say that Wsdesc wg would be interested to get feedback
from people that write wsdl extensions.
-------------------------------------------------------
11:50 Future FTF meetings
- Boston: March 2-3 (Desc), March 5-6 (Arch)
- Rennes: May 12-16 (propose Desc goes first))
Proposal accepted
- Toronto: July 28-August 1 (propose Arch goes first)
Proposal accepted
- West Coast?: mid-September (propose Sydney :-})
Consider West Coast in Sept, Sydney in Nov to combine with AC meeting in Japan.
----[End Joint Session with Architecture Group]----
12:00 Adjourn
---------------------------------------------------------------------
raw IRC log: http://www.w3.org/2003/01/22-ws-desc-irc
Received on Friday, 24 January 2003 14:44:13 UTC