Web Services Description

 

no, I didn't get any errors

I sent my e-mails and they did not show up in the archive

yes, I sent 5 e-mails this morning

<scribe> Scribe: Asir S Vedamuthu

<scribe> ScribeNick: asir

<scribe> Meeting: WSDL WG Teleconference

<scribe> Chair: Jonathan Marsh

Approval of minutes

TonyR: reminds about "the first two meetings for 2005 are listed as 2004-01-06 and 2004-01-13"

Minutes approved

http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/att-0025/20050113-wsdl.html

Review of Action items

[review postponed]

Administrivia

Good Standing discussion

<dbooth> Draft minutes from the F2F:

<dbooth> http://www.w3.org/2005/01/19-ws-desc-minutes.html

<dbooth> http://www.w3.org/2005/01/20-ws-desc-minutes.html

<dbooth> http://www.w3.org/2005/01/21-ws-desc-minutes.html

<dbooth> http://www.w3.org/2005/01/21-ws-desc-minutes.html

[reads thru the good standing list]

In danger: IONA, Agfa-Gevaert, SeeBeyond, DERI, Telecordia, HP, Education.au Ltd.*, CA* (* telcon attendance will restore Good Standing)

Jacekk: changed affiliation

Marsh: Jacekk is in good standing

Next F2F discussion, Mar 3,4 Boston

http://www.w3.org/2002/09/wbs/35125/TP2005/

hugo: requests members to register for the F2F

Last Call Review of WS-Chor LC

http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Dec/0029.html

<Marsh> ACTION: Marsh to send a note to WS-Chor that we have no comments.

Marsh: Kevin reported that there isn't anything to report.. will report that we don't have any comments

Media Type - Issue 272 Architectural issues

[checking on progress]

[skipping because both the editors are absent]

Moving into the import and include cluster

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0058.html

<Marsh> Asir: Sent proposal for 75s.

<Marsh> ... same as 91.

<Marsh> ... about which components are visible within the WSDL.

<Marsh> ... two sections talk about this 3.1, 3.2.

<Marsh> ... 3.1 is about importing schema, 3.2 is about embedding schema in <wsdl:types>

<Marsh> ... I read all the rules about visibility, and they seem correct, but the prose is complicated.

<Marsh> ... Schema WG proposed rewording that I copied into the mail.

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0058.html

<Marsh> Section 3.1.1 [1] - "Note that only components defined in the schema itself

<Marsh> and components included by it via xs:include are available to WSDL.

<Marsh> Specifically, components that the schema imports via xs:import are NOT

<Marsh> available to WSDL."

<Marsh> After: Section 3.1.1 - "Note that only components in the imported namespace are

<Marsh> available for reference in the WSDL document."

[clarifications]

<Marsh> Sanjiva: the imported namespace is... what?

<Marsh> ... finds previous text clearer.

<Marsh> DBooth: Non-normative note giving an example help?

<Arthur> +q

sanjiva: prefers the old wording

arthur: prefers test cases

Marsh: what is wrong with the new wording?

Sanjiva: either works for me with an example

<sanjiva> +1 to what Arthur just said .. non xsd experts like me like schema stuff spelt out :-)

arthur: old wording is clearer to non-schema experts; new wording is clearer to schema experts

<alewis> ack

alewis: are we getting into changing what exists today

[discussion about the clarity of xml schema include and import mechanisms]

Marsh: shall we accept the proposed re-wording, add examples, and make it clear?

<dbooth> +1 to retaining that last negative sentence

asir: describes why the last sentence is confusing, particularly the usage of xs:import within the xs:import section

<TonyR> Perhaps we should say "components ONLY imported via a NESTED xs:import are not visible"

then you have to define what NESTED means

<TonyR> True

Marsh: lets go back to Jeffrey's suggestion to add a table that describes the visibility

<sanjiva> +1 for putting jeffrey's proposed table

<dbooth> +1

<TonyR> +1

mnot: this sounds more like primer text, the table, rather than REC text

Marsh: describing the visibility of schema components is normative
... proposal to accept the wording and add a table that describes the visibility of schema components

[silence]

Sanjiva: sounds good

<Marsh> Table rows/columns: import, include | directly in WSDL, in schema

asir: I would like to see the table

Marsh: proposal to accept the wording and add the table described above

RESOLUTION: Accepted

[section 3.1.2]

Resolution: rewording for section 3.1.2 is accepted

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0059.html

<Marsh> Asir: Proposal for 75t and 92...

<Marsh> ... In part 1 wsdl:include is described as being non-transitive, and that it is modelled after schema include.

<Marsh> ... There is a difference in transitive closure - wsdl isn't, schema is.

<Marsh> ... Schema inclusions are effectively transitive. Why is WSDL non-transitive?

<Marsh> ... Proposed resolution: Replace, "Components in directly included descriptions become part of the

<Marsh> component model of the including description. Directly included means that

<Marsh> component inclusion is not transitive; components included by one of the

<Marsh> included documents are not available to the original including document

<Marsh> unless the are included directly by that document." [1]

<Marsh> With, "Components in the transitive closure of the included WSDL documents

<Marsh> become part of the Description (LC43) component of the including WSDL

<Marsh> document."

Marsh: did we make this intentionally?

Sanjiva: recalls intentional but don't recall the reason why

<Roberto> same here

Arthur: I think this is an error
... part 1 has a proposal to put together a master document and this one is a deviation from that

Marsh: should I follow up with Gudge?

<scribe> ACTION: Marsh to follow up with Gudge on wsdl:include transitive issue

<scribe> [postponed to next week]

<Marsh> Sanjiva: Feb 2004 made the change to non-transitive.

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0063.html

Issue LC52a: Last call review comments (a)

<Marsh> Asir: Unclear whether included components are in the same namespace.

<Marsh> ... The text is inconsistent.

[clarifications]

<Marsh> Proposal: Remove text from Component description in 2.1.1 and 2.1.3, leaving import and include mentioned only in the XML mapping.

Sanjiva: agrees about the target namespace, questions the term 'Extensibility Components'
... agrees with the change

Marsh: changing 'Extensibility' is editorial

[discussion about an e-mail from Arthur - Proposal for Simplification of the Component Model]

http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0060.html

Marsh: push LC52a to the stack and make it dependent on Arthur's issue, yet to be numbered

arthur: describes about several {in-scope-*} for components

Marsh: proposal to accept the resolution and ..

<Marsh> ... realize that there are Extension issues which we'll deal with in Arthur's mail.

<sanjiva> +1

<Roberto> +1 to realize that

RESOLUTION: Accepted

<Marsh> http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html?view=wg#LC60

Issue LC60: Can multiple inline schemas have same targetNS?

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

Marsh: recalling what Basic Profile says about that
... should we make it clear in our spec?

arthur: there is a related issue, about accessing a schema inlined in a WSDL document

asir: recollects what happened 2 years ago and the WSDL wg decided not to allow acces to inline schemas

umit: what is the issue?

alewis: if you have inlined schema, there is no defined method to access it

<uyalcina> I agree with Asir that we are in unchartered territory. There is no composition model from schema about including multiple inlined schemas into a single document. It is undefined with respec to schemaLocation

[I have some offline text, that I will paste it later]

<pauld> BP 1.0a in R2004 disallowed schema import from another document whose root document element wasn't 'schema'.

umit: agrees that there is no composition model and should provide a helpful hint in the primer

<kliu> just want to point out that we have resolve an issue before about "include" inlined schema

<Arthur> +1

<sanjiva> +1 to Jack too .. leave it alone :)

<kliu> in case of "include", schemalocation is an REQUIRED attribute

jacek: don't have to say anything about schemaLocation
... yes, duplicates will be a problem

asir: confused about why we are considering schemaLocation when the issue is about embedded schema

<JacekK> +1 to arthur

Sanjiva: an emedded schema may use schema location

Marsh: appears like we don't want to expand on schemaLocation, we do want to allow multiple schema with the same target namespace, and say something about duplicate components

<uyalcina> +1 to Asir

<JacekK> Kevin, if somebody would want to inline two schemas with the same NS and include between them, they can just fold them in one xs:schema element

<sanjiva> +1 for putting a note saying its ok

Marsh: don't want to change any behaviour on two inline schemas with the same namespace, should we add a note to say what happens to duplicate components

dbooth: we have a question and we should clarify

<Marsh> Proposal: Add clarification that two inlined schemas from the same targetNS are OK...

<kliu> Jacek, yes, in most cases you are right. but some times schemas are generated by tools from different sources and put into wsdl

<Marsh> ... Make duplicate definitions an error.

+1

Sanjiva: shall we stay away from inline schema composition

Marsh: schema doesn't say anything about inline schema composition

<JacekK> Kevin, the process of putting them into WSDL should be simple enough even with manipulating that root element

Marsh: consistent with our past schema decisions on schemaLocation, etc. and leave it up to your schema processor

<Marsh> Alternative proposal: Add clarification that two inlined schemas from the same targetNS are OK.

<uyalcina> +1 to Marsh.

<sanjiva> +1

<JacekK> +1

<uyalcina> WE don't need to solve schema issues further in WSDL.

dbooth: I don't think it is ok to not say anything about two embedded schema with duplicate components

<uyalcina> Our approach has been to leave schema processing issues to schema processor and we should do the same

Marsh: ok to have two inline schemas with the same targetnamespace and wsdl lets the schema processor to figure out

<Marsh> Final proposal: Add clarification that two inlined schemas from the same targetNS are OK. Note that we rely on schema to sort out a coherent set of schema components.

<Marsh> Final proposal: Add clarification that two inlined schemas from the same targetNS are OK. Note that we rely on schema processor to sort out a coherent set of schema components.

<sanjiva> +1

<kliu> +1

RESOLUTION: Accepted

dbooth: in the primer, we have a placeholder for schemaLocation, am looking for a volunteer to help us

<Marsh> ACTION: Marsh to put primer on agenda next wek.