See also: IRC log
<RebeccaB> Scribe: RebeccaB
DONE 2004-11-09: DaveO will recast the @compatibleWith proposal using an extension namespace. (LC54), due 2005-04-13. DONE 2004-11-10: Glen will post an e-mail describing the compromise proposal on formal objections, due 2005-04-11. ?* 2004-11-10: Sanjiva will write up this proposal and email it to the list as a response to the objection, due 2005-04-20. ?* 2004-11-11: Anish to propose additions to the test suite for the purpose of interoperability testing, due 2005-04-13. ?* 2004-12-03: Glen and Asir to help craft the specfic text for the editors (LC18), due 2005-04-13. ?* 2005-03-10: Bijan will look at item Editors to move App C to RDF Mapping spec to see if it is still relavant, due 2005-04-13. DROPPED 2005-03-24: Roberto to draft proposal to split HTTP binding into 3 bindings, due 2005-04-20. DONE 2005-03-31: Paul to raise issue for extensibility/versioning for wsdl using schema 1.0, due 2005-04-13. IN PROCESS 2005-03-31: Marsh to take on (or recommend closing) Bijan's AI to produce a component/property table via XSLT, due 2005-04-28. ?* 2005-03-31: Kevin to fix editorial POST/GET and safety edits, due 2005-04-13. DONE 2005-04-14: Marsh to put RDF mapping on the agenda for next week, due 2005-04-15. ?* 2005-04-14: Arthur to evaluate text from Amy on schemaLocation, due 2005-04-21. DONE 2005-04-14: DaveO to summarize LC77a options, due 2005-04-21. DONE 2005-04-14: Arthur to present a new proposal for LC99, due 2005-04-21.
Marsh: want to go thru schedule, when WG needs to do deep read, etc...
kliu: need two weeks to finish action items on primer
dbooth: primer basically complete, no major portion incomplete
... specific little portions needing fixing
<dbooth> http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/primer-todo.htm
... above is todo list
... one category needs input from others
... volunteers needed
... 1st: Sec 4.1 (Embedding XML Schema):
... unsure if got all rules correct
Arthur: will review
ACTION: arthur to review primer sec 4.1 for correctness [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action01]
dbooth: Sec 5 (More on Interfaces):
ACTION: Kevin to add inheritance example to primer sec 5 [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action02]
Kevin: will take normal one
dbooth: note about adding more MEP use cases
Kevin: need to know what to do with outbound
ACTION: Kevin to do outbound interface example in primer [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action03]
Marsh: Sec 6 (HTTP Binding Extension):
kliu: says only editorial work needed
Marsh: Sec 6.4 (Binding Operations):
kliu: "a target namespace" not really accurate
... primer issue
<dbooth> http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-primer.html#more-bindings-http
marsh: need someone to send comment to comments list
ACTION: kliu will send comment to list as editorial issue [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action04]
<dbooth> http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-primer.html#more-bindings-http
dbooth: Sec 6.6 (HTTP Binding Extension):
ACTION: Hugo to check for correctness [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action05]
dbooth: Sec 7.1 Extensibility:
... check scoping to make sure got all right
ACTION: GlenD to check scoping references [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action06]
<dbooth> http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-primer.html#adv-extensibility
dbooth: Sec 7.9 (Service References):
... schema needs checking
<dbooth> Actually the location of Arthur's ednote is http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-primer.html#reservationList
Arthur: in app namespace can't restrict something from WSDL namespace so cvan't specify binding namespace
... top level can be qualified but nested levels not
... as work-around
... service references are broken
Marsh: lc 117 needs fixing
Roberto: editorial in primer
Arthur: will take section of primer and eliminate broken part
dbooth: may make issue
marsh: like to publish as working draft of primer and get in synch
dbooth: better to publish with problem
ACTION: kliu to note issue [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action07]
dbooth: examples missing type attribute from binding
... unsure of dorchards intent with these examples
... asking kevin to ping dorchard
hugo: http straight-forward example
ACTION: hugo fix type thing and look at rest for consistency in DaveO's examples at http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-primer.html#reservationDetails_HTTP and http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-primer.html#reservationList_HTTP_GET [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action08]
marsh: Sec 7.10 Importing Schemas:
... wait until we finish - work on this PM
... leave ednote in there until solve LC116
dbooth: everything else just editorial
marsh: two weeks action items finished. Then need two weeks for reviewing and feedback
... at least six weeks before we have doc ready for LC
Marsh: primer won't be holding back other specs
dbooth: people should start reading it now
Marsh: ignore typos; dbooth: please report tytpos
Marsh: please review in next four week
Marsh: plan on primer - review primer in four weeks
... synch with other specs
Marsh: completely missed new schedule
... two specs dependent on us - ws-addressing, ws-choreography
... we have 55 LC issues to be addressed; most biggies done
Marsh: will take until next F2F to complete
short discussion on connectivity probles in conference room
Marsh: plan of June to have publication for LC
3 week) LC, exiting in July and try to go for CR in September
<sanjiva> how many impls do we expect to have around to meet CR?
TomJ: ... discussion.. of schedule
hugo: have to make sure we deliver in finitwe amount of time
hugo: if don't meet CR by end of year, I'll probably not recommend continuation
... we should try very hard to reach CR in September
... director will ask "well what about this?"
asir: suggest not accepting any more new features
sanjiva: agree stop accepting issues
... try to go to CR before August break
<jjm> +1
... how many implementation do we need?
Marsh: generally two
sanjiva: Apache is one
asir: one in WebMethods
alewis: Tibco dooing one
... are we allowed to stop accepting issues?
<jjm> jjm: Canon doing one
Marsh: will insitute policy of no more substantive issues during this LC period
... save 'em up 'til later
... try to go to CR before August holifday, which will save us six weeks
... we got heat for not having heartbeat pub
<sanjiva> The Apache impl (the one in Axis2) will be done by/in August I'm sure .. so if Canon gets their one done too then we are in business.
... operations namemapping need update
Marsh: still processing issues - here's progress to date
... propose we re pub part 0, 1 2 in two weeks
<sanjiva> +1 to repub te docs
... as they are today
Marsh: vote to repub doc by end of next week
<Roberto> ping
RESOLUTION: repub doc by end of next week
<sanjiva> hello, anyone there?
RESOLUTION: repub doc by end of next week
<Marsh> Proposal: Put RDDL at the end of the WSDL-defined namespaces only.
RESOLUTION: repub specs 1,2,3 by end of next week
<sanjiva> The current text reads "Note that it is RECOMMENDED that the value of the targetNamespace AII ... and that it resolves to a document which provides service description information for that namespace."
<sanjiva> I'd like to add a phrase at the end like this: ", for example, a RDDL document."
Dorchard: advantage of RDDL is it satisfies both humans and machines
... can define schemas, version, roles
... machines can do so also using xlink attributes
Marsh: we went thru pain in ws-addressing because of new dated versions
TomJ: so RDDL processor can handle that?
dbooth: fragment identifier a little bogus - on dereference, frag ID may not be inside doc
... another deref needed
<sanjiva> While I agree the RDDL processor is indeed mythical at this time, it seems like a pragmatic solution which could be very useful if/when RDDL processors become real. I see it as a "why not?" thing ..
<sanjiva> It could help in the future and it certainly does not hurt us at *all* right now
sanjiva: agree RDDL processor largely mythical
... but no harm in using
Marsh: W3C webMaster decision.
... marsh worried about promoting single format
Arthur: we're not talking about modifying spec
... we want to put RDDL doc to coolect everyrthing for our namespace.
<asir> +1 to Jonathan's proposal
... thing we should have namespace, not bunch of @ signs
... think using RDDL is a good idea
marsh: do we want to have policy as we publish errata with dated versions of our schema?
... latest + dated
TomJ: agree
Roberto: dated spec in addition to dated schema?
Marsh: in end, single namespace, point back to dated versio of spec.
... we can add other links as we desire
Marsh: we resolve fix on errata, it is not normative part so can't call recommendation
... then we batch up and publish 2nd edition
Arthur: let's discuss later, when we are actually publishing errata
ACTION: hugo to establish RDDL doc [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action09]
Marsh: no resources for RDF Mapping update
... postponed
asir: fair to say no resources, no demand?
Marsh: just going to postpone until additional editors found
pauld: my company interested in this so I'll look for resources within
uyalcina: should remove section from primer
Marsh: will yank dangling references from primer when go to LC
http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0025.html
Marsh: put forward 2 alternatives: publish as note; 2: publish several times, get comments - must push out timeline
pauld: we publish as note, ask for comments,
pauld: would help me if we could publish something
Marsh: publish sometghing soon; put in comments about publishing more in future after comment period
asir: other vendors willing to support best practices primer doc?
pauld: thought there would be value
Marsh: if it proves its utility, folks might ask for WG to finish or improive the work
Arthur: targeting specific programming langs
pauld: no
arthur: use code attributes for doing accurate roundtrip
pauld: use dictionary with index
glend: we did this
Marsh: 1) let paul know whetgher can create draft and we will review and publish as note
... any objections?
... not hearing any objections
kliu: put contents in note format?
pauld: will put changes, additions, then put out for review in WG
Marsh: pauld will craft, publish to WG for review and publication as note
ACTION: pauld to craft, publish to WG for review and publication as note [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action10]
(now 10:40)
break until 11:00
Marsh: continuing meeting...
Marsh: dorchard start with MEP stuff, when dorchard gets here LC 51
Marsh: Umit's proposal from last Friday
<uyalcina> http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0090.html
... comment from Sun - annotate types or elements and which is better for generated code
uyalcina summarizes - allowing attr on both elements and types
... in order to recognize, needs to be on complex type
... JAXB can't do anything with it since it generates properties from simple type
glend: they're broken
... can't use type for type
uyalcina: only concern complex name types - for other types, ok
uyalcina: comlex type that's named keeps them from inferring things from i
anish: asking for help for supporting tools
uyalcina: q is to enable only static binding - we should recommend action
misleading) example
misleading) example
sorry - I *hate* this interface! It keeps chopping off half of my input!
discussion of text in proposal
http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0090.html
GlenD: java binding tools have a problem with this usage.
... shouldn't use SHOULD
... would feel better saying it more directly
... there are certain tools that don't have easy time using this case,
... so they shouldn't use this case
... if problem more general then we should further examine syntax
... we need to understand what problem is
... what is it about this case that makes it hard?
Roberto: can't generate class for each element
... have to for type, not for each element
anish: would you be happyu if we make it a note?
GlenD: I'm not OK with confusing wording or if it is about specific problem
Marsh: Glen's case is that we should outlaw cases that allow those toolks to screw up
GlenD: if really generic problem that makes mapping to 3GL or 4GL tools, then we should
... examine problem
uyalcina: they can happily do mapping but cannot do static mapping
Marsh: we're wordsmithing...
anish: I'll talk with Umit offline but don't like the way it's stated
... could conclude that using it on elemnts is never recommended
uyalcina: disagree
Marsh: would anish or glen talke crack at rewording it?
anish: yes
GlenD: yes
uyalcina: don't just cull out JAXB
Hugo: allen wanted to tone down "should"
Allen: no - just want to say here why we're doing it this way
ulyacina: any objection to example?
GlenD: like to see example of use on element as well as type
ulyacina: Henry never formally accepted resolution
... problem?
ACTION: Hugo to take action to check with Henry if accept our resolution [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action11]
anish: did we address Larry's final comment?
... we haven't done that
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Mar/0063.html
Marsh: March 63
Marsh: we're urging them to use care when using wildcards
Marsh: will come back to this after lunch
Marsh: believe we have approval from XMLP WG
ACTION: editors incorporate Larry's changes [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action12]
Topic 74A
Marsh: global search and replace on IRI
Marsh: IRIs allow additional charfacters
TomJ: what are ramifications if we don't do globval search and replace?
hugo: if we say yes do we need to change properties - URI style becomes IRI style, etc.
... discussion on what spec talks about IRIs, URIs, etc
asir: nobody is enforcing relationship IRIs, URIs
Marsh: URIs fuzzy - maybe we should specify targetnamespace must be ASCII
<anish> test
hugo: minimum we update 3986 to 3987
... if someone wants to use IRI they will be able to
<youenn> +1 for IRI
Marsh: strawpoll: 1- update doc to use IRI as accurately as possible
... result - 13
... stick with term URI or localize reference to where it doesn't impact interface?
... result - 1
Marsh: hugo proposed global search and replace.
... I've found places where that is problematic
... let's go through each one
<TomJ> I think that changing URI to IRI will recduce readability of our spec and is not needed
... suggest no change for URI in appendix E
Hugo: sure
<TomJ> I would much rather just change the RFC reference and use URI througout the spec
Marsh: where we have "instance" of URI, we souldn't change that
Marsh: side effect - URI style to IRI style
... in adjunct spec
Roberto: -provides example where IRI style is not URI style
ACTION: hugo look at whether rename URI style to IRI style [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action13]
hugo: change feature attribute to IRI then problem with SOAP which uses URIs
Roberto: in syntax should change name of attribute
<sanjiva> -1 to changing the name of attributes from @uri to @iri!!!!
<sanjiva> argh; that would stink
hugo: we have abstracted SOAP module from soap 1.2, nothing prevents us from having IRI as identifier and say in SOAP 1.2 it;s just an IRI
... change 1.2 to say IRI
<Roberto> or change it to "name" or "id"
Arthur: use "name"
... "name" is an NCName; on interface it's a QName
... talking about the component model
GlenD: thought we had moved to reference
... discussion on what to change name to ...
<Marsh> chad, new vote
<chad> new poll
<Marsh> Option 1: "uri"
<Marsh> chad, Option 1: "uri"
<pauld> option 9: "voodoo"
<Marsh> chad, Option 2: 'iri'
<Marsh> chad: Option 3: "ref"
<Roberto> option 3: "chad"
<Roberto> option 4: "id"
<Marsh> chad: Option 4: "identifier"
Marsh: reason we changed from "name", everywhere else it changes name component
<pauld> chad, options?
<asir> option 5: name
<asir> chad, option 5: name
<Marsh> chad: option 5: "name"
<Marsh> chad, list options?>
<Marsh> chad, list options
<pauld> chad, drop option s
<pauld> chad, list options
<dorchard> dorchard: 2,1
<alewis> vote: 2, 1, 3, 4, 5
<Arthur> vote: 2
<youenn> youenn: 2,1
<dorchard> vote: 2,1
<Allen> vote: 3,5
<TonyR> vote: 3, 4, 5, 2, 1
<asir> vote: 5, 2, 1
<Roberto> vote: 3, 4, 1, 2, 5
<RebeccaB> vote: 3,5
<TomJ> vote: 1,5,4
<pauld> vote: 2, 3
<Marsh> vote: 4, 3
<Marsh> vote: Hugo: 4, 3, 5
<uyalcina> vote: 3, 5
<jeffm> vote: 3,5
<GlenD> vote: 3, 1
<kliu> vote: 4, 2,1
<anish> chad, options
<Marsh> chad, count
<chad> Winner is option 3 - "ref"
<pauld> chad, details
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0057.html
Marsh: proposal - change URI to IRI throughout except URI attr and prop on featiures and properties and SOAP module, which becomes "ref"
... exempt appendix E where we talk about namespace URIs, section 4.11.2 in adjunct spec
... action to continue to look at IRI style/URI style
Marsh: objections?
RESOLUTION: adopted above as partial resolution to change in IRI/URI
break for lunch - resume in an hour
<Marsh> chad, bye
<Marsh> chad, hi
<alewis> Scribe: alewis
Marsh: goals of import and
include
... import and include would work the same as schema, except
chameleon include forbidden
... since then, questions over schema import and include mechanism
give rise to questions of WSDL mechanism.
(issue LC120: contradictions regarding transitivity: http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC120)
Marsh: Roberto suggests fixing broken schema definitions
Roberto: nobody understands it
<Roberto> ping
Amy, Arthur, Tom: well, Gudge and Amy and Arthur do ....
Marsh: what concrete proposals came
out of mailing list thread?
... Arthur proposes changing names in component model to
clarify
... Arthur alternatively proposes modeling import/include as
directed graph of components.
... latter seems contradiction to original goal of abstracting out
import/include
Dbooth: option two doesn't resolve problems. Import/include mechanism in schema different from that presented in email.
Asir: read email, objects that Arthur's example is correct.
Amy: also objects that understanding differed.
Dbooth: wants counterexample from spec
Arthur: error message from spec
Asir: example correct, error message correct; reason why depends on deep study of spec
Dbooth: want spec-based contradiction
Asir: perspective from LC96 (related
to LC 120). Two separate concerns
... first concern: visibility of components in component model
<Arthur> Here is the link to src-resolve: http://www.w3.org/TR/xmlschema-1/#src-resolve
Asir: visibility in the component
model versus visibility in the document ought to be treated as
separate concerns.
... in component set, visibility is complete and pervasive.
Dbooth: clarification requested: once component model constructed, syntactic visibility issues irrelevant?
Asir: correct
Dbooth: once constructed, some components visible, others not?
Asir: no, visibility is pervasive.
Arthur: concept of visibility doesn't
exist in constructed component model
... refers to schema reference pasted above.
... if referring to component with QName that contains a namespace
that differs from the target namespace, then there must be an
corresponding import in the schema containing the reference.
Marsh: this is not about visibility, but about constructing valid references.
Arthur: this is contradiction to Dbooth's conclusion previously posted.
<Arthur> 4.2.2 The ·actual value· of the namespace [attribute] of some <import> element information item contained in the <schema> element information item of that schema document.
Arthur: this refers to QName resolution, which must complete in order to create the component model
Asir: mechanism: xs:include, brings
in components from another schema document.
... mechanism: xs:import, which is also document level, more like
forward declaration.
... signalling that this document will use some foreign
references.
... optionally, may supply hint to help resolve location of
document.
Marsh: doesn't cause components to be sucked in
Asir: correct, doesn't happen immediately, but when constructed then happens.
Umit: at the end, when constructed, there is one component model containing all components
Asir: schemaLocation optional,
processor may use, may ignore, may try to use and fail; no
error
... may fail later, with broken references
Arthur: we don't allow that, maybe we should?
Asir: summarizing, import merely forward declaration, importation happens apart from the statement itself.
Marsh: okay, that's how schema works.
on principle that we ought to work the same (because one def
confusing enough), do we need to change something?
... trying to duplicate schema and failed?
... schema wrong, and we're changing in manner inconsistent with
schema?
Arthur: we are modelled on xs:import, but not the same thing, not direct re-use. Let's spell it out, and be consistent. We don't spell out now.
Marsh: we also permit partial
processing.
... broken references might facilitate that.
Arthur: question is: what is a valid document?
Roberto: aligning with schema is
valuable, but we can differ where the behavior is clearer.
... our include does not behave like an include.
<dbooth> +1 to Roberto
Marsh: how should include work?
Roberto: include should be completely transparent, but it isn't, because the imports are not transitive across include
<dbooth> Roberto is pointing out #6 in http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0129.html :
<dbooth> [[
<dbooth> 6 - not transitive over imports (A includes B imports C =>
<dbooth> A doesn't see C)
<dbooth> ]]
Roberto: this is not an include.
Amy: doesn't work like C include
Glen: lexical text include except that each document must be valid
<dbooth> No, Glen, include is a lexical include with *exceptions*
(dicsussion of examples that are valid/not valid based on how serialized)
ack
<dbooth> Amy: Rather than using wsdl-defined include, how about XInclude?
<dbooth> Jmarsh: XInclude is not very convenient.
Amy: recommend using xinclude instead
Marsh: not entirely convenient.
nested description elements are problematic.
... discussion of how to do this without issues.
Arthur: how do you enforce same namespace.
Roberto, Marsh: you don't (don't need to?)
Arthur: are we willing to depend on XInclude?
Others: we don't have to; we can simply let people do so.
Marsh: XInclude is an infoset
transformation. If we don't exclude the possibility, then the
possibility exists.
... infoset level inclusion.
Arthur: could use entities, for that matter.
Marsh: agreed, perfectly.
Arthur: need to nail down what the
XML document is.
... need strict definition in order to interchange documents.
<dbooth> +1 to Arthur's suggestion to nail down interchange format, though I think this is a separable issue from the import/include issue
Marsh: we could replace wsdl:include with nothing; could replace and recommend/endorse/explicitly permit XInclude.
Roberto: allow import to import same target namespace.
Amy: don't we permit that?
Roberto: no, we don't; specifically disallow.
Dbooth: don't we want transitive import?
Tom: but that adds to the weight of WSDL; requires understanding of XInclude
<sanjiva> +1 for getting rid of wsdl:include .. I fought hard against that when it was put in too (on the basis that modern lanuages have only one include/import mechanism and its usually import and not this textual crap)
Paul: could give examples in primer
Tom: better to use schema model for inclusion than to use XInclude.
<sanjiva> ARGH please don't recommend XInclude; we can just allow import to be used for the same N.
<dbooth> But tom, it's the choice of adopting an existing wheel or re-inventing our own.
Tom: we should use the schema model of import and include
secretary loses the thread by collapsing into helpless laughter as discussion of the manifest virtues of XML schema bubbles
Paul: why would you use include?
Arthur: include allows you to break up a very large namespace into more convenient chunks (fsvo convenient)
discussion becomes general again
Arthur: additional examples/use cases.
general purport of discussion: value of having an include mechanism
Marsh: import of same namespace is
forward declaration that "this namespace is incomplete; components
located elsewhere"
... how would you resolve that?
Roberto: resolve it by resolving
Marsh: but ambiguous; how combine with versions?
Paul: include attractive because it's below the infoset
Arthur: lexical include is dangerous and of less utility; cannot validate independent fragments.
<dbooth> <myNS:include wsdl:required='true' ... /> :)
<dbooth> C #include is well understood. This is a MAJOR advantage!
Paul, Roberto: fragments in many other languages do not require that the fragment be well formed
general discussion about inclusion and importation in various languages.
Tom: this is off the issue; we don't have an issue for this.
Asir: following up: submitted LC96 on
behalf of schema working group.
... Schema WG says "would be nice if wsdl worked like schema, but
it doesn't now, so please don't say it's like schema"
Paul: as a working group, if we don't understand import/include, how can we publish it?
<dbooth> +1 to PaulD's comment!
Tom: we have an idea, and people can understand, and we know what we intend.
Marsh: fix it so it's like schema, or change it and flag the differences.
Arthur: don't think import and
include are broken; some readers have preconceptions, but that
doesn't make the definition broken, just needs clarification
... remove reference to schema and say "this is how it works"
Asir: personal opinion, not schema working group opinion; would prefer to have it work same as schema, approximately
<dbooth> Amy: Tibco was unhappy the addition of wsdl:include because of its complexity. I would be happy to drop it.
amy: tibco wasn't happy to see include; wouldn't mind losing it.
Marsh: let's separate discussion:
import and include
... no one seems to object to import like schema
<dbooth> "When it doubt, leave it out!" :)
Marsh: opinions differ on include,
several possibilities
... no objection to import like schema? (none offered)
... options for include:
... make it work like schema
<dbooth> Options:
<dbooth> 1. Keep wsdl:include and match XML Schema behavior.
<dbooth> 2. Keep wsdl:include but define the behavior to be fully transitive.
<dbooth> 3. Drop wsdl:include, specify physical document interchange format and normally reference XInclude.
<dbooth> 4. Drop wsdl:include
Marsh: drop it completely
... make it work like an include, but not like schema include
<dbooth> 4. Drop wsdl:include and continue to be silent on physical document interchange format.
<Roberto> I think that (2) is more than just transitive.
<dbooth> yes, Roberto. Got a better shorthand?
Asir: there is no open issue on include
Amy: drop of include proposed as solution to other issues, such as LC120.
Marsh: well, let's discuss issues unrelated to include
Arthur: any QName must be imported.
Dbooth: mentions example of A imports B includes C and problems therein.
<Arthur> Proposal: add the following statement: If any component in a document refers to a component in a different namespace then there MUST be a <wsdl:import> for that other namespace in the <wsdl:decription>
Umit: let's just say "works like schema"
Roberto: well, but there may be differences
+1 to Arthur's proposal
Discussion of language in spec.
Asir: section 4.2, two sentences; second sentence unnecessary.
(chasing hyperlinks)
<Arthur> http://www.w3.org/TR/xmlschema-1/#src-resolve
Marsh: that would replace the bulk of [something read from spec]
<Arthur> ok, we will rephrase this in terms of elements and QNames
dbooth: that is phrased as component referencing another component, not as infoset constraint.
Roberto: (sotto voce, pianissimo) agrees
dbooth: read that as a consequence of the rules of the specification rather than as a rule
Marsh: doesn't sound normative enough
<Arthur> Proposal: If a a <wsdl:description> contains a reference to a QName from another namespace, then there must be a corresponding <wsdl:import> in the <wsdl:description>
Marsh: people want to look closely at this wording, best done on mailing list
dbooth: this is an isolated section of the spec, and it's hard to find it, if checking particular parts of a spec.
<Arthur> Put a reference to the "QName Resoultion" section wherever we have a QName reference
Marsh, Tom: should be included in QName resolution.
Marsh: need more complete proposal for fixing.
Arthur: we can add this to QName resolution and add a reference to that section wherever Qname references mentioned.
Marsh: don't change 4.2?
(general discussion, apparent agreement, not clear)
Marsh: add references to qname resolution section, improve qname resolution section, and maybe massage section 4.2.
umit: remove references to transitivity.
dbooth: move transitivity discussion to note.
marsh: fix it or drop it, don't put
it in a note.
... can we close LC120 as editorial; add references to qname
resolution, clarify there, clarify 4.2 (drop transitivity)
<scribe> ACTION: Asir to provide modified text of section 4.2 to editors [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action14]
RESOLUTION: close LC120 as editorial; add references to qname resolution and clarify that section; use Asir's text for 4.2
dbooth: disentangle component model and lexical representation in section 4.2
<dbooth> Asir, in clarifying 4.2, I suggest making a clear distinction between infoset-level constraints and component-level constraints.
<Marsh> ACTION: Arthur to incorporate LC120 resolution, including text from Asir. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action15]
dbooth: what happened to include? postponed?
Marsh: don't have an issue, so postponed/delayed/ignored; going through existing issues.
more discussion of include issue.
Issue: LC89m
Marsh: "directly include" not
useful?
... are we about to drop this section?
Asir: clarifying: namespace a wsdl imports namespace b. all imports must be replicated in b.
Arthur: if b imports other namespaces, then a must also import them.
Roberto: requires a to have internal
knowledge of b.
... description of a complex import chain
Marsh: is this the issue of visibility?
Roberto: isn't there a requirement for direct imports?
discussion of visibility, mechanism of important, schema imports, and visibility
Roberto: what's in the element declarations bag?
Asir: what is imported via xs:import or inlined via xs:schema.
Arthur: those are added to the content model, without necessarily importing the schemas.
Roberto: reads text, asks if this doesn't contradict
Asir: difference between process of importing versus visibility in constructed component model.
<asir> we are talking about section 2.1.3
Arthur: when document b is imported, all components defined in that document are incorporated into the unified set of components.
dbooth: let's change from that model to a different one, with one Description component for each <description> element.
marsh: what's the difference between these issues?
asir: just different focus: wsdl
native components versus non-native (schema) components.
... see section 2.1.3, part 1.
... five rules, first three are native with one set of rules; last
two are non-native with different rules.
dbooth: i think that that section shows that our use of include is confusing.
marsh: when i include a wsdl, the
interfaces, bindings, and services are visible; the inline and
imported schema elements are not.
... could remove include (amy loudly agrees)
asir: solution is to treat non-native mechanism same as native.
marsh: change fourth and fifth rows
of table 2.1 (proposal one)
... drop wsdl:include (proposal two)
<dbooth> Options:
<dbooth> 1. Keep wsdl:include and fix rows 4&5 of table 2-1 to match the other rows.
<dbooth> 2. Drop wsdl:include
chad, new vote
<chad> new poll
chad, question: how to resolve issue 89m (see issues list)?
<Marsh> chad: option 1: Keep wsdl:include and fix rows 4&5 of table 2-1 to match the other rows
<Marsh> chad: option 2: Replace wsdl:include with same-namespace imports
<Marsh> option 3: status quo
<Marsh> chad: option 3: status quo
chad, list options
<asir> vote: 1
<Arthur> Proposal: drop <wsdl:import>, do not require forward declarations, only have <wsdl:include> and make loaction REQUIRED and allow it it inluced same or other namespaces
chad, option 4: redefine wsdl:include to use relax-ng-like include semantics
chad, list options
roberto: explains how relax-ng include mechanism works.
marsh: wsdl-specific smart lexical include
roberto: lexical include that strips the container after checking for match.
<Zakim> dbooth, you wanted to ask what is the benefit of a WSDL-specific include?
dbooth: what is the benefit of wsdl-specific include?
roberto: because it permits tools to be more clever.
dbooth: doesn't see benefit of doing this.
tom: would this be transitive include?
roberto: yes, of course.
chad, list options
<RebeccaB> vote: 4,1
<Marsh> chad: Option 5: Drop wsdl:include
chad, option 5: drop wsdl:include
chad, list options
<dbooth> vote: 5, 4, 1, 2, 3
discussion of what different options mean.
<pauld> vote: 5,5,5,5,5,4
<pauld> chad, list votes
<kliu> vote 1, 2
vote: 5, 4, 3
<pauld> vote: 5,4
<Allen> vote: 4,5,2
<Arthur> Option 6: drop <wsdl:import>, allow different namespace <wsdl:include>
chad, list voters
chad, list options
<Roberto> vote: 4, 1, 5, 2
<dbooth> The status quo wsdl:include is a pseudo-lexical include with exceptions for import and types.
<jjm> vote: 5,4
<dorchard> vote: 2,1
<TonyR> vote: abstain
<Arthur> chad: Option 6: drop <wsdl:import>, allow different namespace <wsdl:include>
<hugo-ms> vote: 1,2
<dbooth> vote: 5, 6,
<RebeccaB> chad: options?
<dbooth> vote: 5, 6, 4, 1, 2, 3
chad, list voters
<Marsh> vote: 1, 3
<Allen> vote: 6,4,5,2
<pauld> vote: 6, 5, 4
<RebeccaB> vote: 4,6,1,2
<pauld> chad, votes?
<TomJ> vote: 6, 4
<GlenD> vote: 1,2
<hugo-ms> vote: 1,2,6
<ugo> vote: 1
<Arthur> vote: 6, 2, 4, 1, 3
<pauld> chad, make 6 win
<jjm> chad, no cheating
chad, whack paul with a voting lever
<uyalcina> vote: 4,6,1
chad, list voters
<jeffm> chat: options?
<jeffm> chad: options?
<anish> vote: 5, 4
<dorchard> vote: 4, 2, 1, 3, 6
<jeffm> vote: 6,4,5,1
chad, count?
<chad> Question: how to resolve issue 89m (see issues list)?
<chad> Option 1: Keep wsdl:include and fix rows 4&5 of table 2-1 to match the other rows (5)
<chad> Option 2: Replace wsdl:include with same-namespace imports (0)
<chad> Option 3: status quo (0)
<chad> Option 4: redefine wsdl:include to use relax-ng-like include semantics (4)
<chad> Option 5: drop wsdl:include (4)
<chad> Option 6: drop <wsdl:import>, allow different namespace <wsdl:include> (5)
<uyalcina> vote: 4, 2, 1, 3, 6
<chad> 19 voters: alewis (5, 4, 3) , Allen (6, 4, 5, 2) , anish (5, 4) , Arthur (6, 2, 4, 1, 3) , asir (1) , dbooth (5, 6, 4, 1, 2, 3) , dorchard (4, 2, 1, 3, 6) , GlenD (1, 2) , hugo-ms (1, 2, 6) , jeffm (6, 4, 5, 1) , jjm (5, 4) , Marsh (1, 3) , pauld (6, 5, 4) , RebeccaB (4, 6, 1, 2) , Roberto (4, 1, 5, 2) , TomJ (6, 4) , TonyR () , ugo (1) , uyalcina (4, 6, 1)
<chad> Round 1: Count of first place rankings.
<chad> Round 2: First elimination round.
<chad> Eliminating candidadates without any votes.
<chad> Eliminating candidate 2.
<chad> Eliminating candidate 3.
<chad> Round 3: Tie when choosing candidate to eliminate.
<chad> Tie at round 2 between 4, 5.
<chad> Tie at round 1 between 4, 5.
<chad> Tie broken randomly.
<chad> Eliminating candidate 4.
<chad> Round 4: Eliminating candidate 5.
<chad> Round 5: Eliminating candidate 1.
<chad> Candidate 6 is elected.
<chad> Winner is option 6 - drop <wsdl:import>, allow different namespace <wsdl:include>
chad, count?
<chad> Question: how to resolve issue 89m (see issues list)?
<chad> Option 1: Keep wsdl:include and fix rows 4&5 of table 2-1 to match the other rows (5)
<chad> Option 2: Replace wsdl:include with same-namespace imports (0)
<chad> Option 3: status quo (0)
<chad> Option 4: redefine wsdl:include to use relax-ng-like include semantics (4)
<chad> Option 5: drop wsdl:include (4)
<chad> Option 6: drop <wsdl:import>, allow different namespace <wsdl:include> (5)
<chad> 19 voters: alewis (5, 4, 3) , Allen (6, 4, 5, 2) , anish (5, 4) , Arthur (6, 2, 4, 1, 3) , asir (1) , dbooth (5, 6, 4, 1, 2, 3) , dorchard (4, 2, 1, 3, 6) , GlenD (1, 2) , hugo-ms (1, 2, 6) , jeffm (6, 4, 5, 1) , jjm (5, 4) , Marsh (1, 3) , pauld (6, 5, 4) , RebeccaB (4, 6, 1, 2) , Roberto (4, 1, 5, 2) , TomJ (6, 4) , TonyR () , ugo (1) , uyalcina (4, 2, 1, 3, 6)
<chad> Round 1: Count of first place rankings.
<kliu> vote: 1, 2
<chad> Round 2: First elimination round.
<chad> Eliminating candidadates without any votes.
<asir> chad: 1, 3
<chad> Eliminating candidate 2.
<chad> Eliminating candidate 3.
<chad> Round 3: Tie when choosing candidate to eliminate.
<chad> Tie at round 2 between 4, 5.
<chad> Tie at round 1 between 4, 5.
<chad> Tie broken randomly.
<chad> Eliminating candidate 5.
<chad> Round 4: Eliminating candidate 1.
<chad> Round 5: Tie when choosing candidate to eliminate.
<chad> Tie at round 4 between 4, 6.
<chad> Candidate 6 has the fewest votes at round 3.
<chad> Eliminating candidate 6.
<chad> Candidate 4 is elected.
<chad> Winner is option 4 - redefine wsdl:include to use relax-ng-like include semantics
chad, count?
<chad> Question: how to resolve issue 89m (see issues list)?
<chad> Option 1: Keep wsdl:include and fix rows 4&5 of table 2-1 to match the other rows (6)
<chad> Option 2: Replace wsdl:include with same-namespace imports (0)
<chad> Option 3: status quo (0)
<chad> Option 4: redefine wsdl:include to use relax-ng-like include semantics (4)
<chad> Option 5: drop wsdl:include (4)
<chad> Option 6: drop <wsdl:import>, allow different namespace <wsdl:include> (5)
<chad> 20 voters: alewis (5, 4, 3) , Allen (6, 4, 5, 2) , anish (5, 4) , Arthur (6, 2, 4, 1, 3) , asir (1, 3) , dbooth (5, 6, 4, 1, 2, 3) , dorchard (4, 2, 1, 3, 6) , GlenD (1, 2) , hugo-ms (1, 2, 6) , jeffm (6, 4, 5, 1) , jjm (5, 4) , kliu (1, 2) , Marsh (1, 3) , pauld (6, 5, 4) , RebeccaB (4, 6, 1, 2) , Roberto (4, 1, 5, 2) , TomJ (6, 4) , TonyR () , ugo (1) , uyalcina (4, 2, 1, 3, 6)
<chad> Round 1: Count of first place rankings.
<chad> Round 2: First elimination round.
<chad> Eliminating candidadates without any votes.
<chad> Eliminating candidate 2.
<chad> Eliminating candidate 3.
<chad> Round 3: Tie when choosing candidate to eliminate.
<chad> Tie at round 2 between 4, 5.
<chad> Tie at round 1 between 4, 5.
<chad> Tie broken randomly.
<chad> Eliminating candidate 4.
<chad> Round 4: Eliminating candidate 5.
<chad> Round 5: Eliminating candidate 6.
<chad> Candidate 1 is elected.
<chad> Winner is option 1 - Keep wsdl:include and fix rows 4&5 of table 2-1 to match the other rows
<jeffm> chad: options?
<dbooth> chad, details?
<pauld> chad, help
general irritation on the results of the vote; the working group declares a break and leaves. :-)
<Roberto> ping
<Marsh> resume
marsh: inconclusive resolution
<Roberto> chad, list options
marsh: is there anyone who can't live with each option?
chad, drop option 2
chad, drop option 3
chad, list options
chad, drop option 5
chad, list options
amy: rants about problems with xml schema include mechanism
arthur: option 6 explanation. wsdl
may contain 6 top-level components, and extensions.
... each component may refer to other components. in this model,
the include happens, and all inclusion is completed prior to
component resolution.
... no forward references; the include mechanism simply brings the
document in and the components become available.
... iri could dereference, could have caching or cataloging
mechanism.
roberto: wsdl a includes b which
imports schema c. what does a need to do to reference components in
c?
... does this lose encapsulation?
arthur: no encapsulation; structure of an included document transparent to includer.
dorchard: is that similar to what roberto proposed?
roberto: difference is whether it's
same-namespace or different.
... prefers keeping import and having a better include; feels that
has better encapsulation.
discussion of nuances of combination with schema inline and import
umit: request for clarification
arthur: why are we treating xs:import differently than other imports?
tom: because those things belong to schema, not to us.
arthur: but once they are exported by schema, they are visible.
asir: only one complaint: chameleon include
amy: complains that asir is misrepresenting her position entirely.
asir: practice comes first:
processors exist, they work.
... if we want to go to last call, we need to stop inventing things
on the fly.
arthur: this is not on the fly; we have been discussing this for some time.
marsh: is our current position workable?
paul: where are the processors that
work?
... the processors that exist do not process wsdl, they process
schema.
paul, amy: our include works differently anyway.
chad, list options
arthur: we should require more overwhelming support to change anything now.
amy: objection to changing rules now.
paul: concerned about level of work, would prefer to simply drop things.
<kliu> +1 to arthur on raising the bar for changes
marsh: re-take poll, options 1, 4, 6.
<kliu> vote: 1
vote: 4, 6
<asir> vote: 1
<dorchard> vote: 4,6,1
<Roberto> vote: 4, 6
<bijan> vote: abstain
<dorchard> vote: 4,6
<Allen> vote: 6
chad, list voters
<uyalcina> vote: 1, 6
chad, close vote
<asir> vote: 1, 6
chad, new vote
<chad> new poll
<Arthur> vote: 1, 6, 4
chad, question: which of three options do we accept?
<Marsh> chad, Option 1: Keep wsdl:include and fix rows 4&5 of table 2-1 to match the other rows
<uyalcina> vote: 1, 4
<Marsh> chad, Option 4: redefine wsdl:include to use relax-ng-like include semantics
<Marsh> chad, Option 6: drop <wsdl:import>, allow different namespace <wsdl:include>
chad, list options
<Marsh> vote: 1
<Allen> vote: 6
vote: 4, 6
<Arthur> vote: 1, 6, 4
<hugo-ms> vote: 1
<asir> vote: 1, 6
<dorchard> vote: 4,6
<pauld> vote: 1, 4, 6
<kliu> vote:1
<bijan> vote: abstain
<anish> vote: 1, 4, 6
<Roberto> vote: 4, 6
<asir> vote: 1
<TomJ> vote: 1,6,4
<uyalcina> vote: 1
<TonyR> vote: abstain
<RebeccaB> vote: 4,6
chad, list voters
<jeffm> vote: 1,6,4
<GlenD> vote:1
<Marsh> chad, count
<chad> Question: which of three options do we accept?
<chad> Option 1: Keep wsdl:include and fix rows 4&5 of table 2-1 to match the other rows (11)
<chad> Option 4: redefine wsdl:include to use relax-ng-like include semantics (4)
<chad> Option 6: drop <wsdl:import>, allow different namespace <wsdl:include> (1)
<chad> 18 voters: alewis (4, 6) , Allen (6) , anish (1, 4, 6) , Arthur (1, 6, 4) , asir (1) , bijan () , dorchard (4, 6) , GlenD (1) , hugo-ms (1) , jeffm (1, 6, 4) , kliu (1) , Marsh (1) , pauld (1, 4, 6) , RebeccaB (4, 6) , Roberto (4, 6) , TomJ (1, 6, 4) , TonyR () , uyalcina (1)
<chad> Round 1: Count of first place rankings.
<chad> Candidate 1 is elected.
<chad> Winner is option 1 - Keep wsdl:include and fix rows 4&5 of table 2-1 to match the other rows
RESOLUTION: issue 89m closed with table 2-1 to be modified as specified.
Issue LC96: wsdl import differs from xml schema import.
asir: we have agreed to align with xml schema import.
RESOLUTION: subsumed by closure of LC 120, changes to section 4.2
marsh: what about test cases? arthur: related to lc 116
Issue 74: can import/include import or include a wsdl 1.1 document?
tom: clarify: say "2.0".
<scribe> ACTION: editors to add "2.0" to document. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action16]
RESOLUTION: LC 74 closed with action to the editors.
Issue LC 75w: should we require resolution of URIs for wsdlLocation?
asir: align with xml schema: not an error
tom: objection: we require location; schema doesn't.
arthur: is a urn dereferenceable?
marsh: but if i have a catalog ....
hugo: what does schema say?
asir: not an error to fail to resolve; is error to resolve to non-schema document.
marsh: someone will take a look?
tom: propose removal of
paragraph.
... amends proposal to remove "is not dereferenceable"
clause.
... if location is dereferenceable and does not resolve to wsdl,
then fault.
arthur: then it is possible to create a valid wsdl document with a completely bogus import.
questions about whether the url must be dereferenceable.
marsh: suppose we change it to
"resolveable".
... remove "is not dereferenceable", leave "resolve".
<asir> It is not an error for the ·actual value· of the schemaLocation [attribute] to fail to resolve it all, in which case no corresponding inclusion is performed. It is an error for it to resolve but the rest of clause 1 above to fail to be satisfied
discussion of how xml schema does include, and why it is so complexly phrased.
hugo: i want to do cheap mirroring using multiple includes with different locations
amy: we encountered this issue before: the location attribute should not be overloaded as a catalog/failover mechanism.
marsh: how much breakage does this bring to our goal of maintaining compatibility with schema?
<Roberto> our purported compatibility with schema, I might say
marsh: can close with no action
<Marsh> ACTION: Editors Fix the "processor" language in 4.1.1 [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action17]
arthur: need to take "processor" language out
<hugo-ms> Previous discussion of this: issue 129 at http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0039
marsh: second option: remove "is not
dereferenceable or"
... objections to second option?
... accepted.
RESOLUTION: Issue 75w closed by directing editors to remove "is not dereferenceable or" from section 4.1.1
<scribe> ACTION: editors to remove "is not dereferenceable or" from section 4.1.1 [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action18]
<TonyR> just don't eat baklava while wearing a balaclava - honey and rosewater in the wool - sticky!!
Issue: LC 59d
<Roberto> http://www.w3.org/2002/ws/desc/4/lc-issues/#LC59d
Choreography group seeks clarification of usage of wsdl:wsdlLocation.
Tom: agree, need clarifying text.
Marsh: this is supplied for the use of other namespaces to allow people to refer to WSDL documents.
Tom: is any of this in the primer?
Marsh: first sentence of section seven describes purpose
<Arthur> I posted the text to resolve LC116 at http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0145.html
Marsh: want editors to add text?
Tom: yes, possibly, but check primer first, see if already there.
<scribe> ACTION: Tom to provide additional text to section 7, part 1, wsdlLocation [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action19]
Issue: LC 116, is schemaLocation attribute required for inline schemas?
Arthur: define inline schema.
... text supplied.
amy: arthur is trying to make sure that valid documents are valid; i want to make sure that there is no wiggle room for invalid documents to be "ambiguously valid".
asir: what section does this go into.
marsh: leave it up to editors
<scribe> ACTION: editors to make sure that inline/embedded schema used consistently and defined. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action20]
discussion of term "encountered".
amy: proposes modification of the language.
roberto: does this confuse resolution with component model.
arthur: describes how component model is built, qname resolution is done.
<asir> +1 Amy's modified wording
change: so long as the inline schema has been encountered during resolution of imports and includes for the current component model.
to: so long as the inline schema has been resolved in the current component model.
RESOLUTION: LC 116 closed with action to editors to incorporate suggested text (see urls).
<scribe> ACTION: editors to incorporate text suggested for resolution of LC 116 in arthur's email http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0145.html as modified [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action21]
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0135.html
<Arthur> LC99: http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0135.html
Issue: LC 99, message reference property has an optional message content model.
arthur: if content model is missing,
it is a non-xml type system, which seems non-obvious
... proposes that the property be required and that an additional
wildcard (#other) be defined, which makes clear that another type
system is in use.
marsh, tom: not a new token in the xml?
arthur: add a new value to the property without changing the xml syntax.
tom: i don't want it to be called
#other, because it looks like something that could show up in the
xml syntax.
... prefer to supply english sentence (marsh obliges with a
clarifying sentence).
arthur: natural reaction to missing value is "null", which is incorrect in this case.
tom: i want it to look different from
the stuff that goes into the wsdl.
... use different enumeration in the component model than in the
syntax.
<Marsh> chad, new poll:
<Marsh> chad, new poll
<chad> new poll
<Marsh> chad, option 1: #other (Arthur's proposal)
arthur: prefers consistency.
<Marsh> chad, option 2: absent property means non-XML type system
<Marsh> chad, option 1: #other means non-XML type system(Arthur's proposal)
<Marsh> chad, option 1a: Option 1 + drop "#" to break the expectation that the enumeration is the same as the XML.
chad, list options
<Marsh> chad, Question: Issue 99 proposals
component model would contain the values: "any" "other" "element" or "none"
xml would contain "#any" and "#none" or an element.
<Marsh> vote: WG: 1a
<Marsh> chad, count
marsh: objections to adopting 1a?
<Marsh> chad, count
<pauld> vote: abstain
<pauld> chad, count
<pauld> chad, list voters
<pauld> chad, count
marsh: hurry up! hurry up!
<pauld> chad, options?
<pauld> chad: mmouse: 1a
RESOLUTION: LC 99 closed with the "other" value added to component model, all values to have octothorpe stripped in component model.
<pauld> chad, count
<chad> Question: Issue 99 proposals
<chad> Option 1: #other means non-XML type system(Arthur's proposal) (0)
<chad> Option 1a: Option 1 + drop "#" to break the expectation that the enumeration is the same as the XML. (2)
<chad> Option 2: absent property means non-XML type system (0)
<chad> 3 voters: mmouse (1a) , pauld () , WG (1a)
<chad> Round 1: Count of first place rankings.
<chad> Candidate 1a is elected.
<chad> Winner is option 1a - Option 1 + drop "#" to break the expectation that the enumeration is the same as the XML.
<scribe> ACTION: editors to introduce "other" value to go with "any" "element" and "none" for message content model [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action22]
Issue: LC 80, extension components not described.
arthur: wsdl has open content model, allows elements and attributes from other namespaces anywhere.
<asir> My response to LC80 proposal is at http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0131.html
arthur: extensions may or may not
contribute to component model
... may add properties to an existing component, or
... may create new components
... extensions very important to wsdl; we use them ourselves and
suggest other people use them.
... we should try to specify what extensions are, so that tools can
be written which are also extensible
... rules (derived by pattern recognition in existing
extensions):
arthur is discussing rules for extensions
arthur finishes discussing characteristics of extension properties, starts on components.
arthur: each component has a
qname
... each component has properties
... each component is or is not extensible.
marsh: objects that don't need qname, just need to say it has a name which is unique in a namespace.
asir: thought that there was a proposal to change all properties in part two to qname.
hugo: worried that this adds yet another mapping to an already complex model.
glen, marsh: requiring qnames to identify extension components and properties is too restrictive.
general discussion of identifiers, fragment identifiers, and so on.
discussion of how to disambiguate extensions in different namespaces but with the same name.
arthur: why not have a qname.
marsh: why have one?
... our equivalent of the localname part is not an ncname.
glen: i want to be able to refer to something outside the namespace.
arthur: web way is uri; xml way is qname.
marsh: too many identifiers, with unnecessary complexity.
roberto: why do we have this?
arthur: spec is vague; this is just a
way of saying what an extension is.
... to design composable tools, need to have more rigor in defining
extensions.
roberto: we have examples in part two; we don't need anything else.
arthur: component model has no formal definition of extension properties or components.
roberto: we don't need this. extensions do it; we don't need to do anything.
arthur: you can't tell from an extension name how it fits in.
marsh: no, you have to read the specification; always do.
arthur: if we don't limit the
flexibility of extensions, it may be impossible to define an
extensible component model.
... that may slow down adoption of extensions
glen: we don't prevent that use case;
however, we also don't prevent the other case as well.
... there may be another way to write the tools, which does
something based on the qnames of extension elements encountered.
don't need to recommend a best practice for the keys of the lookup
table.
hugo: also to avoid collisions.
amy: concerned that this leads in the direction of specifying a processor model.
glen: don't think this specifies that sort of stuff.
umit: does this include specifying fragment identifiers?
arthur: goal already existed; already
in the registration that says that the extension owners need to
define frag ids.
... raises issue: need frag ids for extensions in part two.
<Marsh> ACTION: Part 2 editors to define frag id extensions for soap:header, http:header, soap:module. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action01]
asir: three components in part two, module, header, header.
glen: what's difference between properties and components?
arthur: components contain properties; properties are name-value pairs.
hugo: soap has well-defined extension semantics.
marsh: almost out of time, let's vote.
glen: like general idea, but don't like the specifics.
marsh: can ask whether to pursue or abandon.
hugo: want to know what people think may need changed.
marsh: don't like qnames.
glen: have trouble with some other things
asir: do we need to define this so strictly
glen: put it in the primer?
arthur: no, belongs in part one.
marsh: pursue, or close with no changes.
RESOLUTION: LC 80 closed with no change.