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

Minutes, 21 May 2004 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 24 May 2004 21:49:46 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA203B6C8B1@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Group
Minutes, FTF meeting 21 May 2004
New York City, hosted by IBM.

Friday 21 May

 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Youenn Fablet          Canon
 Hugo Haas              W3C
 Amelia Lewis           TIBCO
 Jonathan Marsh         Chair (Microsoft)
 David Orchard          BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Jerry Thrasher         Lexmark
 Asir Vedamuthu         webMethods
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

 Tom Jordahl            Macromedia
 Hao He                 Thomson 
 Kevin Canyang Liu      SAP
scribe: Youenn
08:00 Issues list review

08:15 Fault Issues
    - Issue 84:  SOAP header faults needed? [8]
    - Issue 62:  Specify a specific SOAP fault code to be 
                 returned [9]
    - Issue 114: Name of wsoap:fault/@name [10]
    - Issue 68:  Confusing description between soap:body and 
                 soap:fault [11]
    - Issue 73:  Clarify Fault versus Body in SOAP binding [12]
    - Issue 29:  How to specify the structure and ordering of 
                 'soap:body' parts [13]  (Obsolete?)

  [8] http://www.w3.org/2002/ws/desc/2/06/issues.html#x84
  [9] http://www.w3.org/2002/ws/desc/2/06/issues.html#x62
 [10] http://www.w3.org/2002/ws/desc/2/06/issues.html#x114
 [11] http://www.w3.org/2002/ws/desc/2/06/issues.html#x68
 [12] http://www.w3.org/2002/ws/desc/2/06/issues.html#x73
 [13] http://www.w3.org/2002/ws/desc/2/06/issues.html#x729

Issue 84: soap:headerFault needed ?
they are not in draft, already gone
RESOLUTION: issue 84 is closed

issue 62: specify specific fault code to be returned
glen: already dealt with that with code and subcode 
RESOLUTION: issue 62 is closed

114: renamed @name to @ref
already done that
RESOLUTION: issue 114 closed

68: confusing between soap:body and soap:fault with the new text and 
parts disappeared.
RESOLUTION issue 68 obsolete

73: editorial pb but obsolete
RESOLUTION: issue 73 closed

29: no more parts
RESOLUTION: issue 29 closed

08:45 Soap:address Issues 
    - Issue 31: 'soap:address' insufficient to describe SOAP 1.2 
                Endpoint [13]
    - Issue 52: Allow operation addresses to be absolute [14]

 [13] http://www.w3.org/2002/ws/desc/2/06/issues.html#x31
 [14] http://www.w3.org/2002/ws/desc/2/06/issues.html#x52 

31 & 52: soap:address issues
Sanjiva:  Now soap binding indicates the protocol and the mep in use.
          soap:adress is now only a URL, so no pb.  Issue should be 
DaveO:    What about supporting the soap/response mep?
Sanjiva:  The soap binding spec has an issue because it always say 
          serialize the soap:Envelope with soap-response has not a 
          soap request 
resolution for 31: we have the information we need one in the binding. 
RESOLUTION: Issue 31 closed, already have protocol and mep in binding.

52: allow operation addresses to be absolute
Sanjiva:  We do not need to change that.
Arthur:   It is about splitting operations to different domains.
Sanjiva:  Point of interface is about collecting a set of operations 
          and bind them together.
DaveO:    The question is about why collecting operations together.
          The pb it is trying to solve is a web pb.
Jmarsh:   Maybe it is about changing the uri scheme on a per 
          operation basis? http and https?
Sanjiva:  If the operations have different scheme/uri, interfaces 
          have no real meaning and collecting operations together 
          has also no real meaning. We should close it and not 
          support it. We have relative uri via @location for the 
          http-binding and interface inheritance. This is sufficient.
Paul:     The issue is about binding each operation to a different 
Sanjiva:  You need to change the interface and put one operation 
          per interface.
Pauld:    We change the abstract level.
Sanjiva:  There is no value in putting operations in the same 
          interface that has a different end point
RESOLUTION: Issue 52 closed: can be achieved by putting one 
            operation per interface and bind the interface to a uri.

09:30 Soap over HTTP Issues
    - Issue 28: 'transport' cannot fully describe underlying 
      SOAP 1.2 protocol binding [15]
    - Issue 61: Additional SOAP binding for HTTP 
      GET-in/SOAP-out [16]

 [15] http://www.w3.org/2002/ws/desc/2/06/issues.html#x28
 [16] http://www.w3.org/2002/ws/desc/2/06/issues.html#x61

RESOLUTION: Issue 28 closed: done that with protocol attribute.

[Issue 61 still open, with proposal, will appear on upcoming agenda.]

09:45 SoapAction Issues 
    - Issue 1: How to specify an empty SOAP action [41]
    - Issues 86: New @soapActionURI? [42]

 [41] http://www.w3.org/2002/ws/desc/2/06/issues.html#x1
 [42] http://www.w3.org/2002/ws/desc/2/06/issues.html#x86

Issue 1: empty soap action
one possible solution: if @soapaction is there, put it even if value 
is empty otherwise, do not put it in.
RESOLUTION: Issue 1 closed, no @soapaction means no header.
ACTION: Sanjiva to implement the resolution that @soapaction not there 
        means no soapaction 

Issue 86: new binding element for soapactionUri?
Glen:     We already have that with @soapaction 
RESOLUTION: Issue closed: we have addressed this with @soapAction

10:00 Soap support Issues 
    - Issue 97:  Schema language for SOAP encoding [43]
    - Issue 99:  Support SOAP 1.2 data model and encoding [44]
    - Issue 100: Support SOAP 1.2 RPC [45]
    - Issue 101: Support SOAP 1.2 transport binding framework [46]

 [43] http://www.w3.org/2002/ws/desc/2/06/issues.html#x97
 [44] http://www.w3.org/2002/ws/desc/2/06/issues.html#x99
 [45] http://www.w3.org/2002/ws/desc/2/06/issues.html#x100
 [46] http://www.w3.org/2002/ws/desc/2/06/issues.html#x101

Issue 97: soap data model and schema language?
Jmarsh:   Should we add this as a deliverable?
Glen:     We have a deliverable to support SOAP1.2 and soap data model
          is part of soap 1.2.
Sanjiva:  This is an adjunct.
Paul:     Jacek wanting a new schema language. SOAP Encoding allows 
          getting this to interoperate.
Asir came with some pbs that will need large amount of work.
Paul:     Benefit from soap encoding is restricting the schema 
          language. The graph part is not very used.
Sanjiva:  Basically this is rpc-literal style.
Glen:     Can we extend rpc style to restrict schema to map better 
          with soap encoding.
Roberto:  Carrying signature is main purpose of rpc style. If we 
          want a restricted schema style, let define another one, 
          compatible with rpc style.
Paul:     It's possibie work is being done elswhere to provide 
          restricted schema language to ease interoperability. 
          We should not redo this work.
Asir:     We are talking about schema for xml fragments. The issue 
          is schema for soap data model.
Glen:     Paul says that the benefit of soap data model is the 
          restriction of xml schema not the graphing.
Asir:     Such a resttriction of schema would be useful.
Roberto:  Feedback that does not reach XMLP wg, soap data model 
          still has graphing and other things. The best thing is to 
          do notinhg because if we restrict soap data model, we 
          will define our own data model, a work that is going on 
Hugo:     How will you do if you want to use soap data model?
Glen:     Need to indicate you use soap data model and define a 
          schema language.
Amy:      Providing an identifier without defining precisely how 
          this works may cause interoperability problems, even 
          with conformant processors.
RESOLUTION: Issue closed: we will not do this new schema language 
            for soap data model.

Discussion about adding style that will ease interoperability and 
map with 3G languages, where to put the bar in simplification.

Issue 99: Support SOAP 1.2 data model and encoding 
RESOLUTION: Issue 99 closed: resolved as a duplicate of 97.

Issue 100 : Support SOAP 1.2 RPC
we cannot support it as it is soap data model related 
RESOLUTION: Issue 100 closed,

Issue 101: Support SOAP 1.2 transport binding framework
Amy:      We support this through F&P and the @protocol attribute. 
          We support use of new soap transport protocols.
RESOLUTION: Issue 101 closed as handled by @protocol and F&P.

11:00 Issue 141: Should WSDL say anything about whitespace in 
                 SOAP:Body? [47]

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

Issue 141: Should WSDL say anything about whitespace in SOAP:Body?
It comes from an interop problem, especially for XML signatures.
Amy:      XML-Sig has solved this through canonicalization transforms.
Jmarsh:   Some processors might remove them or add them. Is it in 
          WSDL scope?
Hugo:     This issue should be solved by SOAP1.2 normalization spec. 
          This is a WG note, that defines a canonicalization.  Not 
          convinced it should appear in the WSDL.
Amy:      This issue might cause pbs for implementers. There is a 
          means of specifying that signature, canonicalization... 
          is turned on, F&P. We should point people to F&P if they 
          need that.
Jmarsh:   Maybe just adding the option at the description level the
          ability to say: add whitespace or do not add whitespace.

RESOLUTION: Issue 141 closed as we don't say how the infoset is made 
            up from the schem-valid data and do not plan to do so 
            F&P can provide means of specifying that signature, 
            canonicalization can be turned on.

xx:xx Schema inconsistencies
    - Issue 19: Inconsistency on optionality of 'soap:headerfault'
    - Issue 44: "name" attribute of "soap:fault" is not defined in
    - Issue 46: "transport" attribute of "soap:binding" should be
    - Issue 47: "soap:operation" should be optional

 [48] http://www.w3.org/2002/ws/desc/2/06/issues.html#x19
 [49] http://www.w3.org/2002/ws/desc/2/06/issues.html#x44
 [50] http://www.w3.org/2002/ws/desc/2/06/issues.html#x46
 [51] http://www.w3.org/2002/ws/desc/2/06/issues.html#x47

Amy:      We could forward this kind of material to soapbuilders or 
          WS-I to fix WSDL1.1 schema.
RESOLUTION: Closed as a group since the soap binding schema is now 
            obsolete. It should be very clear from the spec since 
            we rewrite it completely.

xx:xx New issues from Wed.

Issue 158
resembles 55
Hugo:     Issue is here because of ADD.

Issue 191: MEP
Hugo:     Relationship between wsdl mep and soap mep.
Sanjiva:  Proposal was use SOAP meps. But soap meps are at a 
          different abstraction level. When binding to soap which 
          has two meps, you should indicate which of the two meps to 
          use.  We must say that only specific WSDL meps can be 
          bound to soap meps.  You need to express which wsdl mep 
          mapa to soap mep.
Jmarsh:   We should say something like: "we have the in/out wsdl mep, 
          which can be mapped to two soap specific meps through the 
          soap binding"
Amy:      There was an issue about putting use case or scenarios for 
          each wsdl mep. We can put this information in this section.
          It has never been made.
Jmarsh:   We think about just adding a statement in the introduction:
          "if you are familiar with soap meps, wsdl meps are the same 
          but a little bit more abstract"
RESOLUTION: issue 191 closed
ACTION: Part 2 Editors to add such a statement.
ACTION: Part 3 Editors to add a statement to relate each of the two 
        soap meps to wsdl meps.

Issue 194: syntax

Paul explains his proposal: put all binding info in its own namespace
Sanjiva explains his response of this proposal: attributize as much as
possible binding specific info.
Glen:     The question is: is it worthwhile to have the wsdl namespace
          binding structure at all?
DaveO:    Do we need structure of these extensions we are doing ?
Sanjiva:  With the ones we are doing yes we need that.
DavidB:   Benefit of having a specific syntax: tool can have a partial
          understanding of the binding.
Amy:      We have the hability to specify how that links to the 
          interface structure/operation structure. The connection
          between wsdl:binding/wsdl:operation with 
          wsdl:interface/wsdl:operation is already there. Linkage is 
Umit:     Binding looks like as a template. Linkage is implicit.
Sanjiva:  wsdl editing tool will implement the abstract binding 
          editing and a plug-in  will add specific feature. This is 
          human factor, it is only syntax that helps.
Glen:     It is a little weird to go from one namespace to another one.
DavidB:   Example: tool = find all bindings that have an operation with
          that name.
Paul:     Is it really useful to have the http binding resembles the 
          soap binding ?
Roberto:  The human factor is important. The readability of binding 
          gains of being standardized. Having syntax closer to 
          component model is better.
Glen:     I am not adverse to keeping the structure but I want to 
          know the benefit of that.
DaveO:    There are ways to handle extensions: bottom typing, 
          attribute top typing, other ways. One advantage of Paul's 
          proposal is to allow better schema validation.
Amy:      We have some awkwardness in the WSDL1.1 binding. On the 
          two proposals, Sanjiva's proposal removes awkwardness and 
          preserves the structure which is appealing. Another question
          is: can we mix other namespace bindings elements?
DaveO:    We could define the wsdl:binding type as abstract. The soap 
          binding will extend the wsdl:binding type and soap:operation
          will extend wsdl:operation.
Sanjiva:  But you loose human factor if you do not understand the 
          soap-binding namespace.
Umit:     We can only extend types for schema not elements. This allow
          fix name language.
Roberto:  The resulting schema will be useless (with few constraints)
          or ugly (with all constraints). We should stick with human 
Jmarsh:   Opinions whether binding schema would be ugly or not, 
          writable or not. The schema will not give the abstract 
          informations that daveB and roberto wants to (structure of 
          wsdl:binding/wsdl:operation). Maybe we should investigate 
          a little bit more on hoisting elements to attributes 
          (Sanjiva's proposal).
Sanjiva:  Anything that makes sense to hoist we can. Soap:module 
          cannot be hoisted.
Presentation of sanjiva's proposal.
Roberto:  I like this approach, a small glitch: many attributes from 
          different namespaces. Why not adding a type attribute at 
          the binding level. The value would be a uri, pointing to 
          the binding. If you do not understand this uri, then you 
          will not understand the rest of the binding.
Glen:     The one thing you loose, is elements extensibility, as 
          attribute extensibility is more difficult.
Sanjiva:  We already have this issue.
Discussions about roberto's binding typing proposal. The type added
          by roberto's proposal adds component model constraints.
Consensus of the WG to adopt sanjiva's proposal with roberto's
RESOLUTION: Issue 194 closed by adopting Sanjiva's proposal as amended
            by Roberto (add @type).

Issue 173: do we loose expressiveness by going from element trees to 
attributes for soap fault codes?
Two subcodes below a code/subcode is invalid.
PaulD:    Fault code trees allow documentation that we loose with 
          attributes, but we can put it in other places, inside the 
          wsdl:fault for instance.
RESOLUTION: Issue 173 closed and accept Paul's roll-up.
[Editors have already implemented this change.]

Issue 187:
Discussions about relationships between webmethod and soap mep and
the defaults.
Sanjiva:  We should retain the default values and explain the 
          relationship between webmethod defaults and default meps.
Amy:      We can have an intelligent defaulting mechanism. If you 
          set the defaultWebMethod to get, then the defaultMep if 
          not set will have a default value.
AI for youenn to write up a proposal for intelligent 
webmethodDefault/mepDefault mechanism for the soap binding.
/**** NOTE FROM SCRIBE: ****/
    AI deprecated since webMethod explicit support in WSDL is removed.
RESOLUTION: Issue 187 is then closed as obsolete.

Issue 188: soap:addr http:addr
Sanjiva:  Instead of having an http:address/soap:address element, we 
          could have an attribute (soap:address or http:address).
Asir:     This issue is related with issue 190.

Issue 190: layering
Asir:     We have mep and protocol binding, also applicable to http.
          We can separate the two parts to allow reuse Discussions 
          about how to relate wsdl:HTTP binding options in the 
          wsdl:SOAP protocol in case the SOAP/HTTP binding is in use.
Jmarsh:   Some of the http options (serializations for instance) are 
          not applicable to soap over http.
Asir:     Let's create a list of http options that can be used for 
          soap over http.
Glen:     Some http options in fact should directly go to soap layer 
          slots and not in an intermediate layer like the WSDL 
          component model. The web method attribute is syntactic sugar
          to specify the value of the webmethod property in the 
          property bag. In HTTP this is not the same, it is in the 
          component model and it should be the same, have one 
          property for both http and soap binding. Then we could 
          maybe have the same syntax for both bindings.
Sanjiva:  Pb is that if I write an HTTP wsdl application, I will 
          need to go to the soap spec to specify the web method.
Glen:     We will provide this info in the http binding spec.
Sanjiva:  We could create a new uri for the web method and the 
          binding will tell that this uri will map to the soap 
          webmethod value.
Glen:     The point of F&P was to have a direct mapping between 
          wsdl F&P and soap engine F&P.  Two questions: should we 
          merge the syntax and should we merge the properties.
Sanjiva:  We should also make a list of the properties that can be 
RESOLUTION: Any component model property or F&P property which appear
          both in the SOAP and HTTP bindings we define, will be 
          unified to one property.
[RESOLUTION: Close issue 188, unify @soap:address and @http:address 
             into @address.]
[ACTION: Editors to unify @soap:address and @http:address 
         into @address.]

List of the different binding options and applicability to SOAP & 
HTTP binding.

HTTP                SOAP
webmethod             webmethod        
address               address            
inputSerialization    inputSerialization
outputSerialization   outputSerialization
location              location
separator             separator
version               version
AuthType              AuthType
AuthRealm             AuthRealm
cookie                cookie
transfer-coding       transfer-coding

DaveO:    Two serialization for soap/http. Url-encoded is valid 
          for soap-response.
SOAP does not specify standard ways to map rpc parameters to uris.
We provide one way of doing that in HTTP. We can do that also in 
the SOAP.
Issues for serialization of HTTP are also valid when using SOAP 
over HTTP.
DaveO:    One thing: we could allow url-encoded style for other 
          methods than GET.  input/outputSerialization applies 
          when using SOAP over HTTP discussions about 
          outputSerialization use and relationship with MTOM.

12:00 Lunch

scribe: Sanjiva
raw irc log: http://www.w3.org/2004/05/21-ws-desc-irc.html
Continuing layering discussion ..
Discussion about soap response and its relationship to HTTP GET. 
Asir finds wording in SOAP 1.2 spec which says HTTP GET is what SOAP 
Response MEP is for.

Conclusion that SOAP Response is restricted to GET
It appears that the SOAP spec fixes the MEP -> WebMethod relationship
So, @binding/operation/soap:mep is really not a controllable bit for 

DaveO:    Two things: SOAP Web method feature and actual MEP
Glen:     SOAP HTTP binding gives 1-1 relationship between SOAP MEP 
          and Web method.  However if you invent your own MEP then 
          the relationship can be different/dynamic.
(DaveO is confused; Glen explains further)
Sanjiva:  Proposes to remove the {web method} property of a binding 
          operation component (defined by the SOAP binding).
RESOLUTION: Agreed to remove {web method} property and associated
          attribute.  ;-)
ACTION: Editors to remove the {web method} property from the 
        component model (and related syntax, including defaulting 

Umit:     notes some concern that this action implies someone who 
          defines a new MEP which may want to control the web 
          method doesn't have a way to tweak it.
Sanjiva:  Proposes that with that decision inputserialization and 
          outputserialization are no longer controllable properties 
          in the SOAP binding.
Discussion about the truth value of that proposal.

[Asir: it is not a registered type .. 
[Hugo: http://www.w3.org/TR/html401/interact/forms.html#h-]

Lots of discussion whether we need to provide control over how a URL
is constructed.

Our http binding defines an XML -> URI mapping. Discussion of how we 
should make that be controllable.

Discussion of the value of making the XML -> URI mapping controllable.
Pro: easier to define mapping
Con: too flexible .. not within the 80/20 cut

Jonathan: Points out that making this controllable doens't help more 
          interop: if a person doesn't understand a different 
          serialization then they don't understand the binding .. 
          so its really like a brand new binding indicated deep 
Glen:     points out that this is true about other stuff too .. that 
          any extensibility in the binding may make the binding 

Straw poll: 3 for adding this know, 6 against it

There are folks who object to recording consensus; taking formal vote.

More discussion to try to come to consensus .. not much movement.

Formal vote: add inputSerialization control for SOAP response MEP (or 
some other MEP defined elsewhere)

BT: yes
IBM: no
RogueWave: No
BEA: Yes
Lexmark: no
w3c: no
oracle: no
UMD: abstain
webmethods: no
tibco: yes
sun: yes
sonic: no
canon: no
yes: 4, no: 8, abstain: 1

Decision: no action to add this.

Jonathan asks anyone who wishes to file a minority opinion to record 
such intent by emailing the list.

RESOLUTION: http:inputSerialization will not be added to SOAP binding.

Discussion of whether we should provide some pointers in the spec to 
identify areas which had contention.

Proposal to add ednotes to the spec to indicate such spots.

Consensus to do that.

ACTION: Editors to add ednotes to the spec to indicate areas that had

Proposal to remove the separator property from the http binding.

Accepted as that's not variable per html defined form url encoding 
style which we are using.

RESOLUTION: Remove @separator from HTTP binding.
ACTION: Editors to remove @separator from HTTP binding.

Discussing the location property: do we need that in the SOAP binding

Sanjiva's proposal: Do not allow tweaking the path as soap response 
mep will say how to generate query string.

DaveO proposal: Allow @location attribute on a per-operation basis as
with http binding (with regexp control).

Straw poll: how many people would like to do DaveO's proposal
  for: 4, against: 3
  no consensus

Asir:     This is related to input serialization as if the input ser
          is fixed then why do u want to edit the url.
Glen:     Suggests calling a duck a duck and say that this is 
          basically another input serialization proposal.

[Marsh:   Sanjiva writes:
          <binding type="soap" interface="I1">
            <operation wsoap:mep="s-r" wsoap:location="/temp/{town}" 
          Results in URI: http://something/temp/NYC?zip=10000
          Status quo: http://something?city=NYC&zip=10000]

Suggestion to move this discussion to the mailing list ..

ACTION: DaveO to write up a scenario to motivate path creation on a 
        per-operation basis.

Now considering version, authType, authRealm, cookies, transfer-coding
properties and they would work for the soap binding.

Proposal is to allow the use of http:version etc. properties on the 
soap binding.

Consensus to allow that

RESOLUTION: Allow http:version, http:authenticationType,
            http:authenticationRealm, http:cookies, 
            http:transfer-coding on the SOAP binding.
ACTION: Editors to write up that we allow http:version etc. 
        in the soap binding when the protocol is http.

Discussing soap:address and http:address

Current syntax for endpoints:
  <endpoint name="foo" soap:address="..."/>

Amy's proposal: Introduce optional "address" attribute to 
/service/endpoint to be the address of the endpoint.


RESOLUTION: coalesce http:address and soap:address.
ACTION: Editors to update part 1 to add optional 
ACTION: Editors to update part 3 to remove soap:address and 
        http:address and update binding details accordingly.

RESOLUTION: issue 188 closed per above.

NOTE: issue 189 is the @location issue

Resolved issue 190 closed per agreed to marriage of http and soap 

RESOLUTION: Close 190 per above resolutions.

Now talking about issue 61: soap response MEP
RESOLUTION: Close issue 61, add support for HTTP URI binding rules.
ACTION: 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).

RESOLUTION: Issue 184 to be closed with editorial AI to make sure the 
            wording does not preclude MTOM use.
ACTION: Editors to update soap binding default rules to allow use of 

Issue 178: op safety
RESOLUTION: Move action 178 to a test suite issue as we've done the 
            technical stuff needed.
Issue 187: closed because now obselete (we removed @webMethod)
RESOLUTION: Close issue 187 as obsolete.

Issue 154: need philippe for more info

Issue 155: support for outbound ops in http
ACTION: 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.
RESOLUTION: Close issue 155 with the above editorial changes.

Issue 158: related to ADD; defer

Issue 170: closed due to obseleteness
RESOLUTION: Closed issue 170 as obsolete.

Issue 171: xml version

lots of discussion about merits/demerits
Amy proposes closing without action;
Jonathan provides rationale: there are other serialization options 
that we don't allow control either (charset).
RESOLUTION: Close issue 171 with no action.

16:00 Adjourn
Received on Tuesday, 25 May 2004 01:03:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:40 UTC