W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

Minutes, 17 June 2004 WS Desc telcon

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 18 Jun 2004 17:00:10 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA203FBC56C@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Minutes, 17 June 2004 WS Description telcon

Present:
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Helen Chen             Agfa-Gevaert N. V.
 Roberto Chinnici       Sun Microsystems
 Ugo Corda              SeeBeyond
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Youenn Fablet          Canon
 Tom Jordahl            Macromedia
 Jacek Kopecky          DERI
 Amelia Lewis           TIBCO
 Kevin Canyang Liu      SAP
 Peter Madziak          Agfa-Gevaert N. V.
 Jonathan Marsh         Chair (Microsoft)
 Mark Nottingham        BEA Systems
 David Orchard          BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Jerry Thrasher         Lexmark
 William Vambenepe      Hewlett-Packard
 Asir Vedamuthu         webMethods
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

Regrets:
 Hugo Haas              W3C
 Josephine Micallef     Telcordia/SAIC 
 Jean-Jacques Moreau    Canon
 Arthur Ryman           IBM

--------------------------------------------------------------------
Agenda

1.  Assign scribe.  Lucky minute taker for this week is one of:
      Erik Ackerman, Adi Sakala, William Vambenepe, 
      Prasad Yendluri, Jean-Jacques Moreau, Umit Yalcinalp,
      Igor Sedukhin, Dale Moberg, Paul Downey, Hugo Haas

William for first hour, Prasad after that

--------------------------------------------------------------------
2.  Approval of minutes:
  - June 10 [.1] (corrected)

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0128.html

Approved as corrected.

--------------------------------------------------------------------
3.  Review of Action items [.1].
PENIDNG   2004-04-01: Marsh will get schema tf going.
?ED       2004-04-29: Part 1 editors to adopt Jacek's "purpose of the 
                      binding" text, without "interchangeable"
                      endpoints, and using "confidentiality" (or 
                      similar) instead of TLS.
?ED       2004-05-19: Editors to include in the primer an example 
                      that uses MTOM.  (Issue 72) 
?ED       2004-05-19: Editors to make propogation of modules and f&p
                      use the nearing enclosing scope.  (Issue 180)
?ED       2004-05-19: Editors to fix component model to remove 
                      default* properties, use mapping from syntax 
                      instead.  (Issue 182)
?ED       2004-05-20: Editors to incorporate Hugo's full potato 
                      proposal.  (Issue 54)
?ED       2004-05-20: David Orchard to update HTTP binding to 
                      include discussion of how to generate an 
                      accepts header from schema annotations 
                      conformant to the media types extension 
                      document, and to use outputSerialization 
                      based on that information.  
?ED       2004-05-20: Editors to incorporate http:{properties} into 
                      binding.
?ED       2004-05-21: Sanjiva to implement the resolution that 
                      @soapaction not there means no soapaction.  
                      (Issue 1)
DONE [.3] 2004-05-21: Part 2 Editors to add such a statement. 
                      (Issue 191)
?ED       2004-05-21: Part 3 Editors to add a statement to relate 
                      each of the two soap meps to wsdl meps. 
                      (Issue 191)
?ED       2004-05-21: Editors to add ednotes to the spec to 
                      indicate areas that had contention.  (Issue 
                      190)
?ED       2004-05-21: Editors to remove @separator from HTTP 
                      binding.  (Issue 190)
PENIDNG  2004-05-21: DaveO to write up a scenario to motivate path
                      creation on a per-operation basis.  (Issue 
                      190)

DaveO would like people to comment on his example of HTTP binding usage

?ED       2004-05-21: Editors to write up that we allow 
                      http:version etc. in the soap binding when 
                      the protocol is http.  (Issue 190) 
?ED       2004-05-21: Editors to update part 3 to say that for SOAP 
                      Response MEPs the URI will be generated 
                      following the HTTP binding rules for 
                      generating a URI (for GET).  (Issue 61)
?ED       2004-05-21: Editors to update soap binding default rules 
                      to allow use of MTOM. (Issue 184)
DONE [.2] 2004-05-21: Amy to provide wording to go into spec to say 
                      that our bindings only support the identified 
                      MEPs but others can be handled if appropriate 
                      rules are defined elsewhere.  (Issue 155) 
?ED       2004-05-27: Editors to add http:faultSerialization 
                      attribute.
PENDING   2004-05-27: DaveO will write up better description of 
                      this issue (189).
PENDING   2004-06-10: Jacek to review XMLP specs.
?ED       2004-06-10: Editors should correct issues 208, 213, 
                      215, come back to WG if there are any 
                      questions.

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0079.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0150.html

---------------------------------------------------------------------
4.  Administrivia
  a. - August 2-4 (London)
       Logistics [.1], registration [.2].
     - September 14-16 (Toronto) [.3]
     - November (West Coast) volunteers needed

Volunteers to host nov F2F please make yourself known.

  b. WSDL 2.0 Last Call game plan [.5]
     - 2 hour telcons for next two weeks.  Sorry about Canada Day...

DBooth:   If we slip more than 3 months we need to go to the AC to 
          get reapproval.
DBooth and jmarsh: we can't slip.

[.1] http://www.w3.org/2002/ws/desc/4/04-08-f2f.htm
[.2] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Mar/0064.html
[.3] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004May/0000.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0109.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0108.html

------------------------------------------------------------------
5.  Task Force Status.
 a. Media type description
  - 1st Working Draft Published [.1]
 b. MTOM/XOP
  - Last Call Published [.2]
 c. QA & Testing
  - Suggested QA plan [.3]
  - More details from Arthur [.4]
  - Interop bake-off
 d. Schema versioning
  - Waiting to hear back from Schema on my draft "charter."
  - Henry's validate-twice write-up [.5]

[.1] http://www.w3.org/TR/2004/WD-xml-media-types-20040608/
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0052.html
[.3]
http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/att-0029/QA_Oper
ational_Checklist.htm
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0037.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0019.html

------------------------------------------------------------------
6.  New Issues.  Issues list [.1].
  - Cross-binding HTTP features (Asir) [.2]

Asir raised issue on cross-binding of HTTP features. Discussion of
whether this is editorial as daveO suggested.
Marsh will add this as an editorial issue, for tracking it's quick
dispatch.

  - Mark N's comments [.3]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0080.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html

------------------------------------------------------------------
7.  Issues management [.1].  The following issues [.2] need a champion
to put forward a proposal:
  158 ?        Part 3 Design  Setting HTTP headers in the HTTP binding 

issue 158 - Setting HTTP headers in the HTTP binding
<pauld>
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0109.html
markN:   i'll look into 158
change:  glen and daveO to cover 158

  168 ?        Part 1 Design  Which operation 

issue 168 - dbooth to champion
dbooth:  168 as it stands can be closed quickly but there is a follow-up
issue

  197 ?        Part 1 Design  Don't override interface feature
                              requiredness in binding 

issue 197 - Don't override interface feature requiredness in binding
glen:    i am interested in the issue but i need to re-read it
alewis:  i was part of this discussion and i can champion it
jmarsh:  alewis gets an AI to propose write-up language to resolve 197
ACTION:  alewis to champion 197

  210 ?        Part 1 Design  Refine equivalence algorithm

issue 210 - Refine equivalence algorithm
markN:   i could come up with a proposal but i don't know what the 
         intent of the WG is
ACTION:  markN to put together strawman for 210

  211 ?        Part 1 Design  Omit interface message in binding?

issue 211 - Omit interface message in binding?
jmarsh:  this sounds like an editorial issue
ACTION:  markN to identify where clarification is needed for 211

  218 Paul?    Part 1 Design  Justify interface faults. 

issue 218 - Justify interface faults
ACTION:  PaulD to propose text for part 1 to cover 218

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0109.html
[.2] http://www.w3.org/2002/ws/desc/2/06/issues.html

------------------------------------------------------------------
8.  XML 1.1 issues
  - Issue 174: Tie WSDL conformance to XML conformance? [.1]
  - Issue 175: Is it valid for a XML 1.1 document to import or 
               include a XML 1.0 document (and vice versa)? [.2]
  - Issue 176: Can a WSDL 2.0 XML 1.1 document contain (or 
               reference), a XML Schema 1.0 type description? [.3]
  - Issue 177: Normative dependence on XML Schema 1.0 precludes 
               XML 1.1 [.4]
  - Proposed resolutions [.5]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x174
[.2] http://www.w3.org/2002/ws/desc/2/06/issues.html#x175
[.3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x176
[.4] http://www.w3.org/2002/ws/desc/2/06/issues.html#x177
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html

issue 174 - jmarsh sent a proposal and got +1s
jmarsh:   <summary of proposal>
dbooth:   schema wg looked at it, there were people in favor and 
          some objections. in terms of schedule we can't depend on 
          their resolution.
dbooth:   michael (from schema) did a write-up with several approaches, 
          one of which we could use as an alternative to defining our 
          own type
<dbooth> MSM's proposal:
http://lists.w3.org/Archives/Member/w3c-ws-cg/2004Jun/0005.html
[Plan B: forward motion only on XML
 (B 1) Add the following note after the normative reference to XML 1.0:
       At the time of publication, the version of XML named above was
       current.  All standards and technical specifications, however,
are
       subject to revision, and conforming processors are allowed to
       support more recent versions of XML in addition to the version
       mentioned here.

       In implementing this version of XML Schema, all conforming
       processors[*] MUST support XML 1.0.  They MAY also support XML
1.1
       and/or other later versions of the XML specification.  If a
       conforming processor supports a later version of XML as well as
       XML 1.0, then it SHOULD normally allow the user to control which
       version is actually used; in particular, it is desirable that a
       user be able to request that a document be required to conform to
       XML 1.0, or to XML 1.1 or a later version, or to specify that any
       version of XML is acceptable.

asir:     why not wait for resolution in schema
jmarsh:   we don't have much time...
jmarsh:   we could do something for our last call but note that it is 
          subject to revision based on what happens in schema
asir:     we can ask schema WG to solve this as fast as possible
jmarsh:   would rather not have a dependency for our last call on this
jacek:    to speed things up we could accept jmarsh's resolution and 
          say something like "this is not very important from process 
          point of view and this can change later in the process. we 
          chose to move forward without resolving this fully"
clarification - jacek meant any proposal really
jmarsh:   i can write up a more detailed proposal to have our string 
          and name point to xml 1.1 rather than xml 1.0
dbooth:   would this include datatype definition?
jmarsh:   yes
ACTION:   jmarsh to draft proposal to make wsdl strings refere to xml 
          1.1 and clarifying note
umit:     i am afraid that we are requiring people to be xml 1.1 
          compliant while people use xml 1.0 processors
jmarsh:   there is no dependency on parsing xml, we are based on the 
          infoset (in conformance section)
jamrsh:   i don't believe my proposal requires an xml 1.1 compliant
          processor
umit:     ok, i'll make sure this is the case when you send your 
          proposal
asir:     jmarsh will you define QName and other related types?
jmarsh:   yes. the types that we used that changed are NCName, QName, 
          anyURI and token
issue 174, 175 and 176: jmarsh proposed to close them w/ no action
jmarsh:   any objection to closing these 3?
(clarification) action 5 above (for jmarsh) relates to 177, not 174
<Marsh> RESOLUTION: Issues 174, 175, 176 closed

------------------------------------------------------------------
9.  Issue 212: Explain using bindings across all operations [.1]
  - Mark's proposal [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x212
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0062.html

markN:   (explaining issue 212) noticed there is no easy way to apply 
         same info to all operations in a binding
markN:   the propoasl is that if there is no ref attribute the binding 
         info applies to all operations
tomj:    i like the spirit but i am wondering what we have per 
         operation that we did not roll up to the binding
Glen:    e.g. you might have operation specific binding features that 
         you can turn on and off
roberto: this proposal only covers operations. why not have a similar 
         mechanism for faults?
jmarsh:  let's send this proposal back to mailing list to augment it 
         with faults support
dbooth:  can we have a single consistent mechanism for doing this kind 
         of things

<Prasad scribes}

ACTION: Mark to make a proposal for issue 212 on the list
ACTION: Editor action to check that multiple style values are allowed.


------------------------------------------------------------------
10. Issue 216: RPC and XML Schema not orthogonal [.1]
  - Mark's proposal [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x216
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0064.html

Mark:     provides a recap of the issue.  Definition of the RPC style 
          implies that it can only be used on messages described by XML 
          Schema.  That seems to be an unnecessary constraint. The 
          proposal is a modification of the language to allow any 
          language that results in the same structure can be used with 
          the RPC style.
Umit:     Your proposal remove the MUST adhere to the constraints below 
          and made it "follow the rules". If that is the case I will 
          be objecting to the proposal. I would be happy to take it to 
          the list.
Mark:     Sure.
Jonathan: If the wording is editorial, I would be happy to resolve 
          issue here.
Mark:     Umit wants RFC 2119 level MUST added back
Jonathan: Any objection to closing the issue with the normative MUST 
          adhere to the constraints added (back), as a friendly
amendment?
<none>
Jonathan: Consensus to close issue 216 accepting Mark's proposal with 
          a normative MUST added.
RESOLUTION: Issue 216 closed.
ACTION:   Editors to adopt Mark's proposal for 216, but reword using
MUST.

------------------------------------------------------------------
11. Issue 217: Syntax for multiple styles [.1]
  - Mark's plea at [.2]
  - No new information presented, issue will be closed by chair.
    Allow for minority objection write-ups if necessary.

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x217
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0059.html

Jonathan: Asked for new info why an attribute based extensibility is 
          better? We have gone through this before (issue 98).
          I propose we Close this issue with no action. We don't have 
          any new information.
Mark:     No negative comments on the issue on the list.
Jonathan: There was support for this proposal before but, majority 
          felt they prefer the style attribute in WSDL namespace.
          That was the consensus we reached.
Mark:     Ok
Jonathan: Issue 217 closed.
Jonathan: Checks with Sanjiva if this got reflected in the spec.

ACTION: Editor action to check that multiple style values are allowed. 

------------------------------------------------------------------
12. Issue 221: Identify components by URI [.1]
  - Jonathan's proposes closing with no action.

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x221

Mark:     I am willing to withdraw the issue
Jonathan: I am also proposing we close with no action
Jonathan: Quick summary of the issue. Why are components identified by 
          a QName instead of a URI.
TomJ:     Are you talking of Operation, Port, Interface that kinda
stuff?
Jonathan: Yes, each component has an NCName and a namespace associated 
          with it. When you refer to them from other components, you use

          the QName. Changing all QName refs to URI refs that is implied

          by this proposal is a major change at this point.
TomJ:     Also impacts the usability in a negative way.
Jonathan: Any last comments before this issue gets closed?
DaveO:    We also do have the fact that these components can be
identified 
          by URIs.
Jonathan: Yes, we provide a mapping. 
Sanjiva:  We provide that mechanism.
Jonathan: We don't use the mechanism internally but someone else can.
RESOLUTION: Issue 221 is closed.

------------------------------------------------------------------
13. Issue 222: Name[space] for the intended semantics [.1]
  - Mark's proposal is in the issues list [.1]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x222

Mark:     Proposal change in section 2.1.1: "an unambiguous name for 
          the intended semantics of the components." -> "an unambiguous 
          name *space* for the ..."
DBooth:   I wrote that sentence. I did mean *name* rather than
namespace.
          The intent is that, the targetNamespace URI acts as an 
          unambiguous name for intended semantics of the components as 
          a whole, rather than individual things.
Mark:     If added 'as a whole' I  would have understood it.
DBooth:   O.k. Lets add that or collection of components
Jonathan: So resolutions to change it from "an unambiguous name for 
          the intended semantics of the components." to "an unambiguous 
          name for the intended semantics of the *collection of * 
          components."?
DBooth:   Yes.
Jonathan: Editorial. Any objections?
<none>
RESOLUTION: Issue 222 resolved as above
ACTION: Editors to incorporate editorial fix addressing issue 222.

------------------------------------------------------------------
14. Component model issues
  - Issue 223: Import/include processing model [.1]
  - Issue 224: Formalize component model [.2]
  - Mark's proposal [.3, .4]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x223
[.2] http://www.w3.org/2002/ws/desc/2/06/issues.html#x224
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0085.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0094.html

Jonathan: Considering these together as the proposals came together.
Mark:     This is just an expansion of the introductory text to section
2 
          to talk about what the component model is and how it is 
          structured. Also add a small note regarding the notation of 
          the {} syntax. It would be nice to talk about how new 
          properties can be introduced to the spec.
Jonathan: Basically changes that improve the readability of the spec 
          rather than any features of the WSDL language.
Mark:     There is no guidance on how the properties can be namespaced 
          for extensibility.
Jonathan: The infoset does not namespace properties. Those names are
          namespaced to the specification
Mark:     If we add stuff to Infoset, we can not call the resulting 
          structure an Infoset. We have to call it something else.
Jonathan: For instance XInclude adds a language property to the infoset
Mark:     May be this is a separate issue for XML Core then
Jonathan: Is it not sufficient to identify a property uniquely, by the 
          name of the property and the spec that defines the property?
          The names of the properties don't appear in the syntax. They 
          are referred to by other specifications. Kind of like a 
          QName reference.  Is it not sufficient?
Mark:     It is a good specification to be precise about it.
Jonathan: So, what should the other specifications do?
Mark:     I can come up with a proposal for consideration separately

ACTION: Mark come up with a proposal for extension property namespacing.

Roberto:  Schema itself does not do this for the PSVI. Also for the 
          schema components it does not introduce namespaces for the
          property names.

Jonathan: Going back to the original issues. Any objections to accepting

          Mark's proposals for 223 and 224
Roberto:  In the proposed text do you mean components are "collections 
          of named properties" rather than "named collection of
properties"?
Mark:     Components have names
Roberto:  You mean named as in the kind of the component
Mark:     Would you prefer "type' there?
Roberto:  Yeah, it can be editorial though
Jonathan: Lets get this in the resolution so that editors have it. So, 
          friendly amendment to use "typed components" rather than
"named 
          components". Any other comments?
<none>
Jonathan: Consensus to close 223 and 224 with editorial change proposed.
ACTION: Editors to incorporate proposed resolution for 223 and 224.

------------------------------------------------------------------
15. Issue 207: How to mark which elements to optimize [.1]
  - See thread starting at [.2]
  - Jonathan's proposal based on last week's straw polls [.3]
  - Related issue on F&P? [.4]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x207
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0020.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0139.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0042.html

Jonathan: Proposal at:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0139.html.  
          Proposal was to ask to XMLP WG to add text to the description 
          in MTOM that talks of how to choose things to be optimized.
          Essentially to have the word MAY in there and a reference to 
          expected media-types schema annotation. Say something like, 
          implementations may rely on information in a description such 
          as presence of a value xmlmime:expectedMediaType schema 
          annotation and reference to the specification.
Jonathan: Umit, are you ok with this proposal?
Umit:     Yes, the more declarative power we give the better
Jonathan: You prefer a SHOULD than a MAY or a MUST?
Umit:     Even if we do have a MUST, we have to describe how to do it. 
          Somebody has to provide details on how to utilize that 
          information. If XMLP is going to do further work on MTOM that 
          is better but, I am not sure.
Umit:     If there is are options to serialize oneway or other, some 
          kind kind of capability to specify that I am expecting to 
          serialize this kind of mediatypes as attachments all the time.

Jonathan: Question is, whether that policy needs to be in WSDL
Umit:     As a feature or extension properties that specify expecting 
          to serialize this kind of mediatypes as attachments all the 
          time.
Jacek:    From XOP/MTOM point of view a SOAP node does not know that 
          something was serialized as an attachment. Before the SOAP 
          node processes a message, all attachments are virtually in the

          envelope. So, wondering if we can allow parties requiring
stuff 
          to be in attachments? From SOAP POV this is not wanted. So I 
          agree this is really an optimization and once we start using 
          MUST it stops being that.
Jonathan: Lets see if we can go back and see if my proposal is 
          acceptable enough for us to move on here.
DBooth:   If I understood Umit's concern, it can be accomplished with 
          properties of a feature outside of the WSDL.
Jonathan: XMLP WG would be a better place for defining that feature or 
          properties.
Umit:     That was the question I had. If the XMLP WG is going to 
          take something like on?
Mark:     Probably not.
Umit:     Somebody is going to solve this problem oneway or other. 
          The problem is not going to go away. My concern is who is
going 
          to resolve it.
Jonathan: Can we try and move the agenda fwd. Are there objections to 
          asking XMLP WG to handle this? I proposed some words and a 
          place in the spec where they might do that.
<no objections>
Jonathan: Proposal is accepted and Issue 207 is closed.
ACTION: Marsh to forward Issue 207 proposal to XMLP WG.

Jonathan: A Q about what required means on MTOM feature. If we need to 
          put something in our spec to make it clear.
DBooth:   I wrote up an explanation on this. Some text could be put in 
          the processor conformance section. Section 8.3 ....
Jonathan: Is this non-controversial or need to raise a separate issue?
DBooth:   Only Ugo had a push back:
Ugo:      The push back was on which pov is the interface described 
          from client or service.
Jonathan: We discussed this extensively in the past.
Ugo:      I don't want to revisit the decision
Jonathan: Ack'ing we can't do anything about that, is the proposed 
          change acceptable to all?
<no objections>
ACTION: Editors to incorporate David Booth's clarification in section
8.3
This is also closed.

Reached end of proposed Agenda. Anything else?
Meeting Adjourned.

----------------------------------------------------------------
Summary of New Action Items:

ACTION: alewis to champion 197
ACTION: markN to put together strawman for 210
ACTION: markN to identify where clarification is needed for 211
ACTION: PaulD to propose text for part 1 to cover 218
ACTION: jmarsh to draft proposal to make wsdl strings refere to xml 
        1.1 and clarifying note
ACTION: Editor action to check that multiple style values are allowed.
ACTION: Mark to make a proposal for issue 212 on the list
ACTION: Editors to adopt Mark's proposal for 216, but reword using MUST.
ACTION: Editors to incorporate editorial fix addressing issue 222. 
ACTION: Mark come up with a proposal for extension property namespacing.
ACTION: Editors to incorporate proposed resolution for 223 and 224. 
ACTION: Marsh to forward Issue 207 proposal to XMLP WG. 
ACTION: Editors to incorporate David Booth's clarification in section
8.3 
Received on Friday, 18 June 2004 20:01:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT