Web Services Description F2F - Friday -- 4 Mar 2005

<ht> http://www.w3.org/TR/xmlschema-1/#cNotation_Declarations

<Roberto> Scribe: Roberto

Media Type Description Note

issue 272

henry describing http://lists.w3.org/Archives/Public/public-ws-media-types/2004Nov/0011.html

henry: the problem is not new, and SGML, XML and XML-Schema provide a mechanism to address it (notation)
... is this the problem you are trying to solve?

glen: yes

henry pointing at section 3.12.1 in the schema spec

<Marsh> http://www.w3.org/TR/xmlschema-1/#Notation_Declaration_details

henry: three parts; one (xs:notation) gives a name to things (in the example, "jpeg")
... two, I can declare an attribute of type notation, with the appropriate restrictions
... three, the document looks like <picture pictype="jpeg">...</picture>
... infelicity: the name of the notation is qualified, since it's a schema component
... the advantage of reusing what's in the schema spec outweighs the disadvantage of having to say "image_jpeg" instead of "image/jpeg"

umit: to use it, we'd have to define the type hierarchy in henry's email
... group didn't want to define a type hierarchy, because it's extensible

henry: assume we define a "text" type and somebody defines text/sml
... we probably wouldn't want to retroactively change the existing type
... but we could define a new subtype of notation which is a union of the old and the new
... most common media types have URLs associated to them, which is useful

anish: two questions
... (looking at the example) does it allow me to define a global attribute?

henry: yes

anish: do I have to invent a new attribute for every restriction?

henry: (writing on the whiteboard)
... <xs:schema tns=wsdlbinary" ...>
... <xs:attribute name="contentType" type="my:mediaType"/>
... <xs:simpleType name=mediaType">
... <xs:restriction base="xs:NOTATION"/>
... </xs:simpleType>
... </xs:schema>
... now, in my schema I'm going to say:
... <xs:import ...>
... <xs:attribute ref="xmt:contentType"/>
... this is the minimal solution
... but I could also define a restriction of my:mediaType and use that type for my attribute

asir: could I redefine the xmt:contentType attribute and use the restricted type?

henry: you'd be breaking a good citizenship rule (not redefining stuff in other people's namespaces)
... or, you can use any attribute you want and use the type we define (my:mediaType) or your own
... the motivation for my email was that you are not using validation in your note
... ideally, the note would define both types and attributes, and you'd have two levels of conformance
... for the second level, you need access to type information, much like XML Query does

umit: expectedMediaType is modeled after the HTTP Accept headers, e.g. it has parameters
... how should we address that?

henry: the public identifier in a notation is unconstrained
... but you would have to give names to all the possibilities
... if you define a image type that corresponds to image/*, you also have to stipulate that it matches all the subtypes

anish: so image_any means you should accept any type under it, which requires knowledge similar to the XML Query data model
... how do I find out about a new image_banana type?

henry: using the existing schema mechanisms, e.g. schemaLocation

anish: in the example, the schema would use image_any, but at runtime the instance document uses image_banana
... I could use block="#all" in my schema

<Zakim> Marsh, you wanted to ask about wildcards

marsh: we got comments saying that wildcards are not interoperable, because in practice people accept a limited list of types

see http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0066.html

marsh: also, parameters weren't allowed once, so are they really important?
... so, we could satisfy 80% of our users with a list of types, no wildcards

hugo: for parameters, we found that "q" was useful to express preferences, and we didn't want to preclude others

marsh: but we got there by looking at what Accept supports, not by considering uses

anish: we used to disallow accept params except for q
... but now we accept all params

arthur: notation declarations seem to be rarely used
... in html, the image tag does not use notation
... in xlink, they don't use notation either
... I haven't seen any notation declarations at all, actually

henry: only the schema uses a xs:NOTATION, there are no notations in the instance
... it refers to something in the schema

<dbooth> Roberto: In the input doc, does the media type appear? JMarsh: No. So you have to look in one of the schemas to find out.

<dbooth> Roberto: I would be happier to have a restriction of the public notation.

<dbooth> Roberto: But that's not possible. Then you get into this complicated hierarchical thing that I don't like. It seems useful to have an external identifier that would permit grouping by company for example.

<dbooth> Roberto: It would be much better if you could match a range of public identifiers.

umit: reluctant to go down the type hierarchy route
... i18n told us charset is important for text/* resources

tony: question on henry's email
... xmlmime:text_plain ultimately extends xs:base64Binary
... so it's not plain text?

marsh: all data is base64-encoded, after decoding it you get plain text

anish: we'd need two type hierarchies for base64Binary and hexBinary

marsh: should we pursue notation?

no takers

arthur: notation is exoteric

amy: moreover, notation in schema is not identical to notation in XML

asir: it's an imitation

marsh: do we really need wildcards? or should service authors be explicit about what they accept?

umit: even if we allow wildcards, we should still recommend that people list the accepted types explicitely if they know them

<ht> Jonathan, seem private irc window from me please

umit: it's not a dynamic content negotiation

<anish> larry's issue is 268

<Marsh> http://lists.w3.org/Archives/Public/public-ws-media-types/2005Feb/0002.html

<ht> Roberto, please call Jonathan's attention to my request above

<ht> That's OK, nothing really private :-)

hugo: so now we're considering removing wildcards and parameters?

<jjm> s/network/networked/

anish: if we allow text types, the charset param is useful

umit: language too

anish: that's Accept-Language

<uyalcina> http://lists.w3.org/Archives/Public/public-ws-media-types/2005Feb/0000.html

<uyalcina> the feedback from I18n

[discussion]

paul: with image/*, you know it's some sort of image

hugo: if there's an issue with wildcards, it wouldn't be a big deal to remove them
... */* is useless

<uyalcina> I recommend we put a warning along the lines of : "The intent of the expectedMediaType attribute is to allow WSDL authors to indicate the range of media types that are acceptable for the binary data for which it is defined for, hence it serves as an design time indicator for possible contentType values that are expected. Therefore, authors are recommended to use wild cards with care, and recommended to indicate the list of media types if the set is limite

hugo: text/*, image/* the application probably already has a clue of what it is

<uyalcina> If we were to retain the wildcarding

anish: wrt interop, nobody has to use wildcards if they don't like them
... application/* is meaningless though

roberto: image/* is useful, because a new image/banana type would have to be registered

amy: but image/x-banana wouldn't

<hugo> Hugo: actually, */* _is_ useful; e.g. "image/jpeg" vs "image/jpeg;q=0.9, */*;q=0.1"

<scribe> ACTION: media type editors to add Umit's note [recorded in http://www.w3.org/2005/03/04-ws-desc-minutes#action01]

15 minute break

<pauld> chad, say hi

<dmoberg> chad: help

<Marsh> http://lists.w3.org/Archives/Public/public-ws-media-types/2005Feb/0000.html

looking at i8n issues

<pauld> chad, die die die

RESOLUTION: accept 2a, 2b, 3 from Addison's email

<scribe> ACTION: media type editors to rename xmlmime: to xmime: [recorded in http://www.w3.org/2005/03/04-ws-desc-minutes#action02]

marsh: WSD, XMLP to review the media type note
... get draft in a week, review it for 2 weeks, then publish it

Issue LC106: Revisit LC21 resolution

umit describing issue LC106/LC21

<pauld> chad, start your engines ..

umit: we could have styles in both operation and message

<Zakim> JacekK, you wanted to ask about a one-way style that can be usefully used on either direction

jacek: agress with Umit, would like to see a style applicable to a single message

<uyalcina> the reason that why this was not noticed is because editorial changes that were agreed to are NOT in the cvs yet.

<uyalcina> So it will not be apparent within the current drafts.

s/undone/undo/

asir: does this break only the signature extension or the style itself?
... also, what is option 1?

umit: option 1 is to introduce style in the message and operation
... option 2 is to have style at the operation level but it applies to only one direction
... resolution to lc21 breaks rpc style because there is a relationship between input and output messages

the wrpc:signature extension depends on some requirements being satisfied, and those are listed as part of the rpc style

so if we moved those requirements into the spec for wrpc:signature, the latter would be self-contained

asir: using schema you cannot interrelate input and output messages

dbooth: clarification: so you're saying that we made a mistake in moving the styles attribute
... is the dependency at the schema level or the signature level?

umit: at the schema level

<uyalcina> Here are the relationships that are explicitly defined with respect to input and output in the specification wrt schema:

<uyalcina> Input and output elements MUST both be in the same namespace.

<uyalcina> The complex type that defines the body of an input or an output element MUST NOT contain any attributes.

<uyalcina> If elements with the same qualified name appear as children of both the input and output elements, then they MUST both be declared using the same type.

hugo: we moved it to a message because it was useful there

<uyalcina> The input or output sequence MUST NOT contain multiple children elements declared with the same name.

sanjiva: there is a spec associated with a style URI, and there you can say which message(s) it applies to

<GlenD> Plus, you can still put any other kind of optional notation on the <message> elements that you feel like using attribute extensibility....

sanjiva: agree's with umit's proposal

tomj: +1 to Umit's proposal

asir: we could move the requirements into the signature extension

<Zakim> JacekK, you wanted to say we defined operation style to be able to annotate operations in some way, RPC style is an example of that; message style - message annoations - have a

<Zakim> hugo, you wanted to explain motivation for change and to and to give more motivation about leaving it at the message level

<JacekK> there I go...

hugo: I agree it's useful at the operation level
... but also at the message level
... the uri and multipart styles constrain the input message only
... it's a schema constrain on an "in" message
... if we wanted to support out/in with the HTTP binding, we couldn't use these styles anymore

<pauld> chad, say hi

<sanjiva> I do not accept that multiple style attributes is without cost - the *USER* pays a major cost in having to learn yet another feature that 90% of the people will never use.

<alewis> chad, new vote

<chad> new poll

<dbooth> Option 1: (status quo) style only at message level

<dbooth> Option 2: Style only at operation level

<dbooth> Option 3: style at both operation and messaage level

<alewis> chad, question: where should style be specified?

<alewis> chad, option 1: (status quo) style only at message level

<alewis> chad, option 2: style only at operation level

<alewis> chad, option 3: style at both operation and message level

we should define the uri and multipart styles so that they apply to in-first and out-first meps

jacek: can we have "styles" on interfaces? on bindings?
... so we either have one or zero
... one meaning on operation only

<alewis> chad, list options

<JacekK> chad, option 4: drop style altogether

<sanjiva> Jack: if you drop style altogether then how would you do the RPC stuff?

<sanjiva> chad, option 5: drop wsdl altogether

<JacekK> instead of style="rpcstyleuri" do rpc:style="true"

<sanjiva> Jack: pls read the spec .. we've done that already

chad, option 6: style only at the operation level plus fix the uri/multipart styles

<anish> chad, option 7: drop the component model

<Marsh> chad, drop option 5

<Marsh> chad, drop option 7

<Marsh> cahd, options?

<Marsh> chad, options?

<alewis> chad, list options

* chad question: where should style be specified?
* chad     option 1: (status quo) style only at message level
* chad     option 2: style only at operation level
* chad     option 3: style at both operation and message level
* chad     option 4: drop style altogether
* chad     option 6: style only at the operation level plus fix the uri/multipart styles

<alewis> chad, drop option s

<JacekK> chad: 6, 4

<Allen> chad: 6, 2

<alewis> vote: 3, 6, 2,

<dmoberg> chad: 2, 6

<TomJ> chad: 6, 2

<RebeccaB> vote: 6,2

<uyalcina> chad: 6,2,3

<TonyR> chad: 2, 3, 1, 6

<hugo> chad: 3, 6

<pauld> vote: 4, 2

chad: 6, 2, 4, 1

<youenn> chad: 6,4,3

<dbooth> chad: 3, 6, 2, 1

<asir> chad: 3, 6

<Marsh> chad: 6, 3

<jjm> chad: 6,4,3

<JacekK> sanjiva, where is it in the spec?

<alewis> chad, list voters

<dorchard> chad: 6,2

<anish> chad: 6, 2, 1, 4

<JacekK> sanjiva, I did suggest how to do that and heard no problems with it

<uyalcina> chad: 6, 2

<ARyman> chad: 2

<sanjiva> vote: 6, 2

<GlenD> chad: 6, 2

<alewis> chad, list voters

<alewis> chad, count?

<chad> Winner is option 6 - style only at the operation level plus fix the uri/multipart styles

<anish> chad: count

<alewis> chad, details?

<charlton> chad: 6, 2

<ARyman> chad: 6, 2

<Marsh> chad: count

<alewis> chad, list voters

<Marsh> chad: count?

<dbooth> chad, count

<chad> Winner is option 6 - style only at the operation level plus fix the uri/multipart styles

<dbooth> chad, details

* chad Election: where should style be specified?
* chad Method: British Columbia STV
* chad Number of Ballots: 22
* chad Threshold Name: Droop Static Whole
* chad Threshold Value: 12.0
* chad Delayed Transfer of Surplus: Not Enabled.
* chad Batch Elimination: None
* chad 5 candidates running for 1 seats.
* chad  R|   1|   2|   3|   4|   6|Exha|Surp
* chad --+----+----+----+----+----+----+----
* chad  1| 0.0| 2.0| 4.0| 1.0|15.0| 0.0| 3.0
* chad Round  1: Count of first place rankings.
* chad           Candidate 6 is elected.
* chad Winner is 6.

<alewis> chad, list votes

strawpoll: option 6 wins

no objections, option 6 is accepted

<alewis> chad, say hi

RESOLUTION: option 6

<sanjiva> no one in wsdl seems to understand what "over-engineering" means :-(

<alewis> new vote

<alewis> chad, new vote

<chad> new poll

<alewis> chad, question: how should we specify these styles?

<asir> sanjiva, that is over-engineering :-)

<alewis> chad, option 1: hugo's proposal, list the meps with which each style works.

<alewis> chad, option 1: roberto's proposal, list the meps with which each style works.

<alewis> chad, option 2: hugo's proposal, specify that the style may be used for any mep with an initial message

<alewis> chad, list options

<dbooth> chad, option 3: list the meps and specify how each works with the style, but don't preclude the use of other meps

<alewis> vote: 2

<alewis> vote: 2, 3

<sanjiva> chad: abstain

<hugo> chad: 2,3

<uyalcina> vote: 2, 3

<Allen> chad: 2, 3

<youenn> vote: 2

<TomJ> chad: 2

<dbooth> chad: 2, 3

vote: 1,3

<anish> chad: abstain

<Marsh> chad, list options

<TonyR> chad: 2, 3, 1

<ARyman> chad: list options

* chad question: how should we specify these styles?
* chad     option 1: roberto's proposal, list the meps with which each style works.
* chad     option 2: hugo's proposal, specify that the style may be used for any mep with an initial message
* chad     option 3: list the meps and specify how each works with the style, but don't preclude the use of other meps

<hugo> chad: 2,3,1

<RebeccaB> vote: abstain

<alewis> chad, list voters

<asir> chad: 2, 3

<Marsh> chad: 2, 3

<charlton> chad: 2, 3

<ARyman> chad: 2, 3

<JacekK> vote: abstain

<dmoberg> chad: 3

<pauld> vote: 2

<alewis> chad, list voters

<dbooth> chad, count

<chad> Winner is option 2 - hugo's proposal, specify that the style may be used for any mep with an initial message

<dbooth> chad, details

* chad Election: how should we specify these styles?
* chad Method: British Columbia STV
* chad Number of Ballots: 15
* chad Threshold Name: Droop Static Whole
* chad Threshold Value:  8.0
* chad Delayed Transfer of Surplus: Not Enabled.
* chad Batch Elimination: None
* chad 3 candidates running for 1 seats.
* chad  R|   1|   2|   3|Exha|Surp
* chad --+----+----+----+----+----
* chad  1| 1.0|13.0| 1.0| 0.0| 5.0
* chad Round  1: Count of first place rankings.
* chad           Candidate 2 is elected.
* chad Winner is 2.

RESOLUTION: option 2 is accepted

<scribe> ACTION: part 2 editors to implement resolution to LC106 [recorded in http://www.w3.org/2005/03/04-ws-desc-minutes#action03]

s/part2/part3/

More RPC issues

issue 75e: http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75e

marsh: return the predefined extensions spec to MEPs and keep RPC style where it is

asir: move rpc style to a separate section

umit: we decided to move all styles to part 2

what if another extension comes up?

hugo: have a single spec with bindings, styles, meps

rename part 3 to "adjuncts"

marsh: "extensions" sounds better
... proposal: fold parts 2 and 3 into a single document
... that includes the rpc style

no objections to the proposal

RESOLUTION: fold parts 2 and 3 into a single document

<sanjiva> chad, wake up dude

<alewis> chad, new vote

<chad> new poll

<alewis> chad, question: what shall we name part two?

<alewis> chad, option 1: Predefined Extensions

<alewis> chad, option 2: Adjuncts

<GlenD> chad: 2

<alewis> chad, option 3: Bindings, MEPs, Styles

<Allen> chad: 2

<sanjiva> chad: 3

<alewis> chad, list options

chad, option 4: Extensions

<dorchard> chad: 2

<JacekK> vote: 2, 4, 1

<asir> chad: 2, 4

<anish> chad: 1, 2

<dmoberg> chad: 1, 4, 3, 2

<dorchard> chad: 2,4

<RebeccaB> vote: 2,3,4,1

<hugo> chad: 2, 4, 3

<alewis> vote: 3, 1, 2, 4

<youenn> chad: 2,1,4

<TonyR> chad: 2, 3, 4, 1

<uyalcina> vote: 2,3

<hugo> chad: 2, 4, 1

<alewis> chad, list voters

<sanjiva> chad: 3, 41

<Marsh> chad: 4, 2, 3

<sanjiva> chad: 3, 1

<alewis> chad, list options

<ARyman> chad: 4, 1, 2, 3

chad: 4, 1, 2

<TomJ> chad: 4, 3, 1

<alewis> chad, list voters

<jjm> chad: 2

<alewis> chad, count

<chad> Winner is option 2 - Adjuncts

<alewis> chad, details?

<alewis> chad, list options

RESOLUTION: call it "Adjuncts"
... close 75e as duplicate

<scribe> ACTION: editors to merge parts 2 and 3, move the rpc style from part 1 into it and name the result "Adjuncts" [recorded in http://www.w3.org/2005/03/04-ws-desc-minutes#action04]

Issue LC75g: RPC should allow element wildcards

http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75g

[discussion]

tomj: it's as intended, rpc style disallows wildcards

sanjiva: they can write their own style if they want to use wildcards

marsh: microsoft has a community interested in rpc style

tomj: how would wildcards work?

<sanjiva> chad, new poll

<chad> new poll

we could support one wildcard; Java 5 has varargs in the form of a "Object..." parameter

marsh: strawpoll on closing the issue

<jjm> abstain

10 yes, 4 no

marsh: any objections to close the issue?

objects

bijan: when closing a last call issue, we still need to get assent from the submitter

arthur: it wasn't discussed on the mailing list, lack of discussion indicated lack of interest

<scribe> ACTION: roberto to come up with a proposal for LC75g (wildcards in rpc style) [recorded in http://www.w3.org/2005/03/04-ws-desc-minutes#action05]

Issue LC75h: Disallow multiple returns in RPC

http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75h

sanjiva: if your language doesn't support multiple returns, you'll never run into this case when generating wsdl

glen: only one return value

<sanjiva> roberto: leave it as is

umit: leave it as is

marsh: add a clarification saying why multiple returns are allowed

<TomJ> I agree with the issue and think we should limit the rpc style to a single return value to make the mapping much simpler for all languages

<pauld> many brain-dead languages only have one return value

<alewis> chad, new vote

<chad> new poll

<TomJ> and many of these languages are far more popular and in use than the non-braindead languages

<alewis> chad, question: how do we handle return values in rpc style?

<alewis> chad, never mind.

marsh: question: should we limit rpc style to a single return value?

<alewis> chad, question: what's for lunch?

yes 4, no 8

<jjm> no

<bijan> Putting aside brain deadedness, several of the multiple return languages in question aren't really niche (Perl, Python, Ruby) and we heard a report that a clearly dominant language (Java) is adding it

marsh: any objections?

<alewis> chad, option one: dinner

<alewis> chad, option zero: breakfast

marsh: any objections to adding a clarification to the spec?

<alewis> chad, option minus-one: nothing

<TonyR> chad: option five

RESOLUTION: close 75h by adding rationale for multiple returns to the spec

<scribe> ACTION: editors to add to rpc style rationale on allowing multiple returns [recorded in http://www.w3.org/2005/03/04-ws-desc-minutes#action06]

<bijan> (A note: http://www.kdedevelopers.org/node/view/321)

<bijan> (A note: http://www.kdedevelopers.org/node/view/321 )

RDF mapping modeling decisions

Component model changes

<anish> http://lists.w3.org/Archives/Public/www-ws-desc/2005Mar/0006.html

LC89l - drop component model

bijan: we didn't find that the component model brought value

sanjiva: for LC89k, we decided not to remove inheritance

rich: the component model adds too much complexity

bijan: the component model isn't designed for end-users

rich: wsdl should be designed for people, not tools
... when writing a wsdl, to know if there are any conflicts you have to mentally build the component model

glen: somewhere we have to describe the constraints we can't write in schema

marsh: component model helps with imports/includes
... with infoset-only, you have to follow the infoset chain whenever you run into an import/include

arthur: issues with dealing pure infoset
... component model shouldn't allow things we cannot represent as documents
... infoset is only about single documents, but we need to be able to modularize
... an xml document includes a lot of incidental information, e.g. order (operations are unordered for our purposes)
... or the distinction between attributes and elements

<bijan> er..

rich: everything else in web services is infoset-based

<bijan> s/doesn't find/finds/

<dorchard> BEA made some proposals on simplified syntax at http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0071.html

rich: the first thing users run into is WSDL, and that uses another layer

sanjiva: value of the component model is in flattening imports/includes
... if we go with the infoset, we create a new spliced infoset for a document that doesn't exist
... two options
... we create a fictitious infoset with extra properties

<Zakim> dbooth, you wanted to mention that this the lion's share of the problem of spec complexity that we recognized earlier and DaveO, Jonathan and I looked at.

sanjiva: or there is no fictitious infoset, and references are resolved by navigation

<dorchard> sanjiva, is this like a "pan infoset" model?

<sanjiva> dorchard: not sure I understand what a "pan infoset" model is ..

<dorchard> sanjiva, an infoset is an xml "document" based abstract model. Thus to talk about multiple infosets, there needs to be a model for the multiple infosets..

<sanjiva> So the scenario I had was a.wsdl imports b.wsdl and includes c.wsdl. So we already have those 3 infosets. Now when u "load" a.wsdl what you will get is not the infoset for a.wsdl but that of a "virtual" document.

<dbooth> 1. The complexity of our spec is a *major* problem. I've been a part of this WG for years, and still find it difficult to figure out the answer to detailed questions that arise.

<dbooth> 2. Normal developers *will* need to read our spec as a reference, to answer specific language questions that arise.

<dbooth> 3. Aside from the inherent complexity of the WSDL 2.0 language, the extra level of abstraction that the component model introduces is the major cause of spec complexity.

<sanjiva> dbooth, right I agree. but what one could create a new infoset for a "virtual" document right?

<sanjiva> s/dbooth/dorchard/ sorry

bijan: users may read the spec if a language lawyer issue comes up, but regular users won't

<dorchard> sanjiva, yeah. So there's 3 infosets, and then there needs to be a way of talking about the multiple infosets.

<sanjiva> followup to dbooth: I have never read the schema spec .. I've found the primer quite enough. really.

anish: pointing to bijan's comment to the mailing list
... editors have to edit the spec in 7 places

<dbooth> Although it would be a major effort to rewrite the spec in terms of infoset instead of component model, I think it has potential for being a major improvement to spec readability.

<sanjiva> dorchard: Yeah .. I'm not too happy about this change but I don't see how we can have the "beauty" of a collapsed "component model" without doing it.

umit: got feedback that people like reading wsdl 2.0 better than wsdl 1.1

marsh: lunch break

L U N C H

will resume at 1pm

<Allen> Resuming after lunch

component model

<scribe> Scribe: Allen

LC 89i: Drop component model

Rich: Need to understand WSDLand SOAP to do web services, not just use tools.

Everything in web services now is infoset based. WSDL is not.

scribe: Developers need another mental information model to understand WSDL

<sanjiva> q[

scribe: component model hurts reuse

Glen: Component model provides step along way away from english to describe meaning of WSDL
... 2 Not all web services specs are infoset based, eg WS-Addressing

Rich: I meant the information model.

<uyalcina> +1 to Glen

Asir: +1 to Glen

<sanjiva> +1 to Asir

Asir: In November f2f we talked about component model. People were excited. Now we are having an openended discussion on same topic. Need a champion and we need proposals before proceeding.

<uyalcina> +1 to Asir, Clapping loudly

<Marsh> acvk ar

Arthur: could eliminate component layer by talking about 2 things, document based on infoset, and deal with single documents at a time not collection of documents. Need to talk about what we mean by a collection of documents.
... chapers would be "description element", "interface element", only talk about what is directly in the element.

Glen: need to talk about behavior, not just syntax

JM: how do you deal with import, include?

Arthur: have a document collection, what does it mean for the set to be consistent, what properties does the collection have.

<Zakim> JacekK, you wanted to say everything XML-data-oriented is infoset-based, we aren't data-oriented

<dbooth> +1 to Arthur's idea

Jacek: Want to react to comment that everything else uses infoset. In WSDL we are not about XML we are about describing interfaces.
... this discussion is useful so we can explain why we have component model.

<pauld> +1 to Arthur

Jacek: component model tells what WSDL does. Then we describe how to turn into XML.

DaveO: Find Rich's comments compelling. Can simplify spec for end users, and toolkit writers. BEA believes that WSDL 2.0 doesn't hit the mark of making it each to describe web services.

Bijan: Concerned that component model is more expressive than what we can serialize. Would like discussion in spec about rationales for component model.

DDaveO: YaronG wrote a discussion published by WebDav that does this.

Paul: you want a book to tell you how to read the book?

JM: a few sentences about why we use component model.

[discussion about readability of WSDL spec}

<bijan> I think that the spec is for *expert* users

<Zakim> Marsh, you wanted to ask about the transition from WSDL component model to Schema component model

Sanjiva: spec is not meant for endusers. This was a conscious decision.

<bijan> Or users willing to be experts

<bijan> Vague specs are bad for users!

Hugo: If you want to define as infoset you need to talk about endpoint and binding, thought you end up with something like the component model. Maybe we can simply make the compent model simpler.
... put the XML first and then follow with the component model.

<Zakim> JacekK, you wanted to say shortly that we may have it the wrong way around with imports and includes and to say shortly that it's those who write WSDL (not just tool implementors)

Jacek: Ways to simplfy the component model. Intead of component model abstracting away details, add details for serialization. Separate parts for language lawyers.

Sanjiva: Component model is for implementors. Users don't need to read it.

<Zakim> bijan, you wanted to reply to JacekK

Bijan: Much more beyond include, import that component model abstracts.

<Zakim> hugo, you wanted to ack Asir's return by a poll :-)

Hugo: Can we take a poll to see where people stand?

<sanjiva> I'm very supportive of writing a document about "why is WSDL 2.0 like this" .. if others want to collaborate and write a public document pls let me know!

<pauld> chad, toss the dice :-)

<bijan> sanjiva, I'm game

<sanjiva> bijan, let's start a wiki somewhere and get going on it ..

<bijan> Good idea

<bijan> There should be a wsdl 2.0 wiki anyway

Arthur: My interest in Z is to make the spec precise. Z is not an end in itself, could throw it away once done and the information would still be there.
... a number of issues introduced by introducing a component model. Should simply the spec to solve those rather than making the component model work with those issues.

<dbooth> chad, question: Is the complexity/readability of our spec an important enough issue what we should pursue ways to improve it?

Arthur: recommend removing concept of component and talk about document and collections of documents.

When we talk about collections of documents we talk about equivalence. Hope that we can make that simple.

Arthur: need to talk about equivalence now anyway.

<dorchard> why can't we just straw poll?

<dorchard> or maybe we should have a straw poll for "also deliver for wsdl document authors"

Arthur: volunteers to remove component model.

<pauld> less working parts means fewer defects

<dbooth> chad, reset

Sanjiva: Removing the component model may introduce additional defects. A lot of work to find and fix the defects. A lot of work for a small audience, implementors.

<chad> new poll

DaveO: do we sant to consider document authors?

<dbooth> chad, question: Is the complexity/readability of our spec an important enough issue what we should pursue ways to improve it?

<uyalcina> we specifically have a document called primer for the users

<dorchard> question: should we target wsdl document authors aka end-users with WSDL 2.0?

<ARyman> there are always user guides and reference manuals

Poll: close the issue with no action.

yes 8

no 6

Formal vote.

<Marsh> s/Formal Vote/Objections to closing with no ACTION: Yes/

<Marsh> Objections: to _not_ closing with no ACTION: Yes

<anish> we should not use xml schema part 1 as our model or rationale for complexity. I do appreciate the complex issues. Do note that WS-I is having discussions about creating a XML Schema profile

Formal vote

Web methods: yes

IBM: yes

CA: abstain

BEA: no

Cyclone: yes

SAP: yes

Tibco: yes

Oracle: no

Canon: yes

Insbruck: yes

Mindlab: yes

Sun: yes

Roguewave: no

W3C: no

Iona: abstain

BT: no

Microsoft: abstain

Issue closed with no action

LC89g

Sanjiva: we never mean XML representation. We don't deal with XML only XMLinfoset.
... The psuedo schema shouldn't be in the same section as the infoset representation.

Rich: XML representation refers to the serialization.

Arthur: removing component model would allow description as info set items rather than components.

JM: issue is editorial.

LC81

Arthur: Does the compent model need to be more general than the document?

general agreement - no

<bijan> +1

Accepting proposal for this issue would allow editors to make changes anytime it is found that component model allows something documents do not.

Resolution: proposal is accepted.

LC105

JM: do we allow property extensions at top level or just annotations?

Roberto: a top level extension affects its parent (description) which affects its children.

Sanjiva: what is an example of a top level extension?
... ... that affects one of our components.

Roberto: top level extensions that are not required cannot change the parent.

Amy: what is an example of something that changes the semantics of an interface?

Arthur: One type of change - adds something to the component model.
... more restrictive equivalence - must come from the same document.

Roberto: a mandatory extension can change the semantics of its parent, including top level. Already in the spec.

Arthur: current definition of equivalence is problematic. Need to fix that.
... can we live with document equivalence where infosets must be identical?

<JacekK> bijan, can we in our mapping tables add the appropriate sameIndividualAs?

Arthur: if an interface gets the same operation in multiple ways how may operations are added to the component model?

[ concensus seems to be one]

<bijan> JacekK, sure. Why not :)

Arthur: what is the uri?

[concensus seems to be one from each parent]

Arthur: is that ok?

[concensus seems to be yes]

Arthu: spec says that we collapse components that are identical.

Sanjiva: Only with inheritance.

Arthur: can get identical components by including documents that use the same interface. How many copies do we then have in the component model?

Break

<asir> http://www.w3.org/TR/2004/WD-wsdl20-20040803/#compequiv

Back from break

Arthur: section 2.17 defines equivalence of components.

Sanjiva: This section was intended for comparisons between WSDLs.

Arthur: would this apply to components within a component model?
... how do you resolve a reference to a component?
... there must be an id, and there are properties, some are references to a component. How do we compare equivalence?

Amy: the only way there could be equivalence is through inheritance.

Arthur: I would like that to be the case.

Umit: but they can have multiple identifiers.

<dbooth> Arthur's example on the board:

<dbooth> [[

Arthur describes the problem: one document with two interfaces, each with the same operation. Do we have two operation components?

<dbooth> ]]

[concensus yes]

Arthur: are they equivalent?

[ yes ]

Arthur: Can have two components that are equivalent, as defined in 2.17, since they have the same name, but are different.
... with two includes with top-level components with the same name we would get this situation.

Sanjiva: we need to say that we can't have more than one component at the top level with the same qname.

<scribe> ACTION: editors need to add constraint that top-level components must be unique. [recorded in http://www.w3.org/2005/03/04-ws-desc-minutes#action07]

Arthur: equivalence is only interesting at the top-level so we don't need to define it for nested components.
... repeated operations should be illegal (both cases from LC105 description)

<asir> +1 to Sanjiva

Arthur: add constraint cannot have multiple operation components with same qname.
... if we add parent property to operation component then we can check for equivalence. Same for faults.
... only nested components would have parent property.

Umit: first example should be legal. What is the problem?

Arthur: hard to test equivalence.

JM: no benefit to allowing this.

Asir: for schema components, we have multiple designators and one of them is canonical.

JM: does having a parent component fix the problem?

Arthur: yes

Poll, do we want to introduce parent property to nested components.

Yes - 12

No - 1

<scribe> Done

4 Mar 2005

Attendees

Contents

Media Type Description Note

Issue LC106: Revisit LC21 resolution

More RPC issues

Issue LC75g: RPC should allow element wildcards

Issue LC75h: Disallow multiple returns in RPC

RDF mapping modeling decisions

Component model changes

LC89l - drop component model

component model

LC 89i: Drop component model

LC89g

LC81

LC105

Summary of Action Items

Scribe.perl diagnostic output