W3C home > Mailing lists > Public > www-ws-desc@w3.org > March 2003

Minutes, 3 March 2003 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 5 Mar 2003 12:31:03 -0800
Message-ID: <330564469BFEC046B84E591EB3D4D59C099D3FDA@red-msg-08.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Monday 3 March
09:00 Introductions and logistics

 David Booth            W3C
 Glen Daniels           Macromedia
 Dietmar Gaertner       Software AG
 Martin Gudgin          Microsoft
 Tom Jordahl            Macromedia
 Jacek Kopecky          Systinet
 Philippe Le Hégaret    W3C
 Amelia Lewis           TIBCO
 Kevin Canyang Liu      SAP
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle  (Tuesday only)
 Dale Moberg            Cyclone Commerce
 Don Mullen             Tibco
 Arthur Ryman           IBM
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates
 Jerry Thrasher         Lexmark
 William Vambenepe      Hewlett-Packard
 Umit Yalcinalp         Oracle
 Allen Brookes          Rogue Wave Software
 Steve Lind             AT&T
 Lily Liu               webMethods
 Jean-Jacques Moreau    Canon
 Sanjiva Weerawarana    IBM

 Simon Genzer           Iona Technologies  (for Adi)
 Marc Hadley            Sun (for Roberto)
 Martin Chapman         Oracle (for Jeff)
 Abbie Barbar           Nortel
 Harold Boley           NRC
 Eric Prud'hommeaux     W3C
 Yves Lafon             W3C
 Carine Bournez         W3C
 Ray Whitmer            AOL
 Tim Berners-Lee        W3C

 Roberto Chinnici       Sun Microsystems
 Youenn Fablet          Canon
 Adi Sakala             IONA Technologies

    - Assignment of scribes
      Jeff Mischkinsky, Jerry Thrasher, Dietmar Gaertner, Allen Brookes,
      Glen Daniels, Umit Yalcnalp, Kevin Liu, Jacek Kopecky)

Monday AM: Jacek
Monday PM: Dietmar
Tuesday AM: Philippe
Tuesday PM: Jerry

[scribe: Jacek]
09:20 Properties and Features 
    - [relevant materials from PFTF]

Gudge:    Why is soap:header not sufficient?
GlenD:    You might have related headers and a spec that covers them all
[GlenD:   Four things we're trying to express:
          1) A particular feature is OFFERED
          2) A particular feature is REQUIRED
          3) A particular property is CONSTRAINED
          4) A particular property is GIVEN A VALUE]
[Arthur:  is 4) simply an extreme case of 3) ?]
Amy:      don't interpret this as negotiation
DavidB:   that's how I interpreted the first two
GlenD:    WSDL shows what's available
[marc:    so does abstract bit of WSDL do the requiring and the binding 
          do the offering ?]
[GlenD:   (marc, right) Example:
            <feature url="securechannel" required=true/>
            <soapmodule uri="securemodule"/>
[marc:    that implies there are validity constraints between abstract 
          and binding related to the features required/offered]
[GlenD:   correct]

some discussion on whether it needs to go into portType

Arthur:   if it's abstract, it goes into portType
GlenD:    Features are abstract, the particular implementations are concrete.
          This potentially goes into the realm of WS-Policy.
jeffsch:  why wouldn't you put it on messages?
Amy:      it's still sort of fuzzy where this should go.
GlenD:    while you could have a feature that goes on input and not on 
          ouput, I don't see it going onto messages.
jeffsch:  I'm wondering whether we really want to put this on portType and 
          possibly make portType something bigger than it is now.
GlenD:    With respect to the MEP stuff, it's whole separate can of worms.
          They are related, though.  There is a question on guidelines on 
          how to write specs.  In WSDL we should focus on what we have to 
          expose.  The idea of P&F is being able to say: I'm running this 
          service, there is an extension (not just a header) that you 
          should use when talking to the service.
MartinChapman: that's exactly what I see WS-Policy doing.
TomJ:     A feature says "there is a policy here and I want you to stick 
          to it when talking to me"
Amy:      it depends on what you're writing you WSDL for.  It would be 
          nice to have a standard way of expressing usage of a feature 
          and combinations of features.  If two specs need correlation 
          IDs, they can reuse a common way of correlation.  With P&Fs you 
          can just refer to a property instead of reinventing it every
          time. In MEPs, we do a similar thing.
GlenD:    So MEP is a kind of feature but it's called out as a first-class 
          thing because it's so "core".
Amy:      features represent static state, MEPs represent dynamic state
umit:     it really sounds to me like MEPs are a subset (scribe: use?) of P&F
GlenD:    An MEP is one type of thing you might do with the P&F.  But 
          there's a whole lot of other stuff, too, and it may be orthogonal 
          and combinable.
DavidB:   The capabilities of MEP specification is a subset of P&F 
          specification's capabilities
Amy:      MEPs specify a lot of state
umit:     we had spent a lot of time about combining MEPs, doesn't 
          combining P&Fs become the same kind of problem?
Amy:      currently, there is inadequate attention to modularization of specs
jeffsch:  I don't see this proposal as really helping with these problems. 
          An existing correlation ID needn't work for some applications 
          so they will recreate their correlation. And the P&F spec doesn't 
          really help.
Amy:      If you define you properties and make them more visible, there's 
          a greater chance of reuse. There are some things you want to 
          reference in the WSDL, like HTTP content negotiation
GlenD:    what we want to do is pretty simple: we want to provide a 
          well-known slot where you put this kind of information in the WSDL
jeffsch:  is this a recommendation on how to write specs?  SOAP 1.2 features 
          are not used much yet
GlenD:    yes, but while our P&F potentially opens a can of worms, it may 
          be a can that's already open by SOAP extensibility model. It's 
          easier to share the concept of a property than a generic WSDL 
          extensibility element
[jjm-RNS: +1 to what Glen just said]
Don:      it also makes it easier for implementors
Jonathan: I still don't see a huge difference between a feature URI and a 
          WSDL extension element QName
GlenD:    P&F gives you a common way to constrain values, for example. That's 
          a common expressive power that you'd have to specify over and over 
          in generic extensions
jeffsch:  this P&F defines a pattern for extensibility
GlenD:    yes, and it might not fly, but we may try
Amy:      we're providing a syntax for people to do some stuff in a common, 
          easily recognizable fashion
jeffsch:  one of my points is if the soap:binding itself is motivated to 
          this degree of generality
GlenD:    some of the earlier proposals were to stick this into the SOAP 
jeffsch:  the question is: is this more than a SOAP binding thing?
GlenD:    the pattern in general is usable elsewhere, too, e.g. in the 
          HTTP bindings. So we're trying to pull out a general pattern 
          of extensibility. Another nice thing is that when you start 
          tagging things with URIs it may connect us with RDF and 
          Semantic Web
jeffsch:  a common way of converting QNames into URIs should suffice.

10:20 Break
10:40 Properties and Features (cont.)

GlenD:    P&F is factoring out some expected common functionality of 
          WSDL extensions
Don:      the user interface might be simplified with properties and 
GlenD:    so it should be in the portType to be able to express policy
Jonathan: let's explore the downside of us not accepting this
GlenD:    we need a way of expressing in the SOAP binding the stuff that 
          SOAP 1.2 does.  soap:module was approved, but there is more 
          than that.  To satisfy our SOAP 1.2 requirements, P&F could 
          be in the binding level. The rest is an expected commonality 
          of WSDL usage.
Jonathan: but we don't have much evidence people are going to write 
          their specs in this fashion yet
[jjm-RNS: Some people are.]
Philippe: there are two other Working Groups working on stuff that may 
          use the mechanisms
[jjm-RNS: WS Arch is looking into this problem as well.]
jeffsch:  even if this was not taken upon by WSDL 1.2, it could still 
          live outside (in a note, for example)
[jjm-RNS: The SOAP Abtract Attachment Feature specification was written 
          using this model as well.]
jeffsch:  this topic is on this position of the agenda because many 
          other issues are potentially dependent on this
[jjm-RNS: +1 to jeff]
Jonathan: there is the question of what this does to the abstract 
          component model
jeffsch:  my guess is that this ends up adding to the component model.
          So it's not purely a syntax then. Seems like a list of 
          properties on each operation (or on a portType).
GlenD:    and on the binding
jeffsch:  it's not a list, it's a set
GlenD:    there's a set of features (at each level)
Amy:      would properties show up in portType or in binding?

[property] component is a URI and a constraint
[properties] is a set of [property]
it would go on operations, bindings, possibly portTypes

Gudge:    an extension could set the predefined properties in WSDL
igors:    with extensions we don't have to change the abstract model.
          I want to be able to focus on the core description of 
          porttype without properties and features
Gudge:    what's the difference between putting P&F into component 
          model and having this as an extension?
igors:    we can make P&F an extension syntactically and the component 
          model could be tweaked
sanjiva:  I'm concerned about the relationship to Policy. You can 
          certainly represent P&F as extension, just as Policy does it
Jacek:    what uses for P&F do we have in sight in WSDL?
Philippe: since more than one spec is going to use this, why don't we 
          put it into core?
GlenD:    until people start writing stuff according to SOAP 1.2 
          extensibility model, it's not going to have any "concreteness".
          We may give it a more real, concrete meaning in WSDL
Lily:     functionality-wise, WSDL features are the same as SOAP 
[sanjiva: except for design time vs runtime]
Jonathan: SOAP has features, and that would be generalized beyond SOAP 
          into Web Services features and properties
TomJ:     why is this controversial?
jeffsch:  minimal-change?
TomJ:     my processor may easily ignore this change
GlenD:    there's the wsdl:required bit
TomJ:     people are not shouting for this stuff
Jacek:    adding P&F into portType might change the understanding of 
          portType's function
DavidB:   it's a trade-off between adopting a more general solution 
          and a number of ad-hoc solutions
TomJ:     Amy says she needs this
[sanjiva: yep frame the grid guys!]
Amy:      right
Gudge:    1) are we interested in taking this forward, 
          2) (second-order) is this an extension or core
Jonathan: 1) does *this group* want to take this on
Philippe: we have a task force so we seem to have the resources
GlenD:    third path: let's hold off on P&F and dive into specific 
          things that have depended on it. It might be enlightening 
          on the need (or lack thereof) for P&F
DavidB:   it sounds like a good idea
Jonathan: I get a bit worried about putting off such a big thing
DavidB:   the specific uses might demonstrate the need for P&F
Jonathan: it also depends on whether there are going to be many uses 
          for P&F outside of WSDL
GlenD:    the one-offs in WSDL will be examples of P&F use
DavidB:   let's take a straw-poll to see how many people want to 
          deal with P&F now; if there are few such people, we may put 
          it off
Jonathan: we want to ask whether we want to drop this completely
DavidB:   the question might make sense to wait
Jonathan: we want to see the leaning on that, too, now
DavidB:   three-way poll
[Marsh:   Option 1) work on it now
          Option 2) wait till we resolve some dependent issues
          Option 3) drop it now]
Jonathan: the PFTF has overgrown it's charter already, we've also 
          seen some interest from outside this WG. We might 
          recharther the PFTF. Any concerns with the three options 
          as stated?
results:  option 1) 16
          option 2) 6
          option 3) 2
Jonathan: we seem to have significant support for working on it now.
          How do we want to proceed? Syntax, questions?
[voices propose syntax discussions first]
jeffsch:  I propose me and JJM to show how it works for the soap 
GlenD:    we have some syntax but I dont' want to show it as the 
          agreed result of PFTF
[alewis:  <feature uri="anyURI" required="boolean" />
            AND EITHER:
          <property uri="anyURI" constraint="QName" />
            OR both:]
          <propertyValue uri="anyURI">anySimpleType</propertyValue>
          <propertyConstraint uri="anyURI">QName</propertyConstraint>
GlenD:    properties are shared by features, not really owned. 
          Properties should not be inside features because there is 
          a single property space
Jonathan: features and properties are two top-level things, properties 
          can be associated with features, WSDL doesn't model that
Gudge:    there are two top-level spaces? There may be interaction 
          between features and properties but WSDL doesn't say?
GlenD, Jonathan: right
GlenD:    Features specify value space constraints for properties
sanjiva:  I understand props and features as abstract stuff and 
          implementation info
GlenD:    a property is more like "which particular encryption method 
          you're using for a security feature". Or what the possible 
          timeout values is on reliability
sanjiva:  there's another URI, for a SOAP module, that's independent?
GlenD:    SOAP module URI is SOAP-specific
Jacek:    and the SOAP module could implement WSDL features
sanjiva:  I have to see concrete, specific scenarios
GlenD:    for us the interesting part is that something in the 
          binding implements the features. The properties from the 
          WSDL point of view are the aspects of the features that 
          the user is interested in
Jonathan: I'd like to see how P&F would affect the component model 
          before diving into syntax. And how inheritance affects this
[marc: is multiple inheritance a given ?]
jeffsch:  it seems that if P&F are on operations, it's already solved
[Gudge presents a take on how the component model would look like]
Gudge:    binding component would include two additional properties: 
          [features] and [properties]. You don't want a feature to 
          be able to add properties
GlenD:    yes
Gudge:    the [properties] property is a set of Property components.
          But it doesn't *do* anything!
TomJ:     it's just hints for the processor
umit:     this seems like a meta-level definition and it should be 
          elsewhere. What you're trying to do can be done externally 
          to the portType
Jacek:    it's a matter of drawing the line of what porttype does
DavidB:   it's also very subjective issue

12:00 Lunch
[scribe: Dietmar Gaertner]

13:00 Properties and Features (cont.)

[plh-lap: http://lists.w3.org/Archives/Public/public-ws-pnf-tf/2003Feb/0058.html]
[Amy explains the syntax proposal.]
Amy:      feature bits seem to be non-controversial
[properties: create a restriction in the types section and reference 
          it as a QName]
Gudge:    spec says: each property has a schema type
Amy:      is the proposal that properties can have complex type? That
          is a larger problem!  Property definition should be simple; 
          just a value or enumeration of values
Glen:     property value: either value or constraint
[plh-lap: <wsdl:property uri='anyURI'>
            <wsdl:value>list of strings</wsdl:value>
[Marsh:   <wsdl:property uri="anyURI" type="QName"?>content?</wsdl:property>]
Sanjiva:  syntax looks like the syntax for defining a WSDL policy
Jonathan: policy also contains compositers
Glen:     Cool if we could merge the syntax-es
[Marsh:   Some options:
          <wsdl:property uri="anyURI">
          <wsdl:property uri="anyURI" type="QName"?>content?</wsdl:property>
Sanjiva:  better to come up with a proper syntax offline
[plh-lap: <wsdl:property uri="anyURI" type="QName (XSD type)"?>
          [type and content are exclusive]]
[GlenD:   So you can say: "the property 'http://foo' is an xsd:int']
[Gudge:   So, I remain confused about what the propertyValue/Constraint 
          elements map to at the component level]
Sanjiva:  how to extend this to do the policy stuff etc.
[GlenD:   (you say that in your spec) Then you can say:
            <schema namespace="http://blah">
          <complexType name="t">
            <restriction base="xsd:int"> 
              constrain to 5..10 ....
          <property uri="http://foo" type="blah:t" 
          <property uri="http://foo" xmlns:blah="http://blah">5</property>
          (apologies for terrible and wrong schema above)]
[sanjiva: Gudge will now point out all the errors ;-)]
Tom:      ... fears that this makes the spec way too complicated...
Glen:     example: Axis message context
Tom:      feature with 3 properties, all on/off style
Glen:     there needs to be some code artifact that corresponds to the 
Tom:      to you allow me to constrain a complex type?
Amy:      Why do we need a complex type here?
Glen:     SOAP decided not to restrict from beeing complex; maybe this 
          is a reason to do it...
Amy:      simple value (embedded) is something that will be used 80-90% 
          of the time. (to Glen) give me a feature the needs a complex 
[discussion goes back and forth about simple type vs. complex type 
property values...]
Tom:      wants a very straightforward syntax. Prefer the service to be 
          declarative about the properties
Glen:     syntactical representation (of complex case): define a 
          restriction of a complex type
Jonathan: worried about an 80% case for an extensibility model
[... discussion back and forth again whether features and properties 
are at all needed, and whether simple model or complex model is 
required and so on and so on ...]
Glen:     come up with a (complex) example, maybe in the next break...
Jonathan: which syntax is preferred? (single line vs. two line)
Glen:     contraint expressed in the WSDL decreases the probability 
          that the client sends wrong messages
Marc:     how to make sure that the binding is covered by a feature?
Glen:     there has to be some text in the WSDL spec that describes 
          the validation process
Jonathan: new syntax proposal: propertyValue / propertyConstraint
[plh-lap: <wsdl:propertyConstraint uri='anyURI' type='QName'/>
          <wsdl:propertyValue uri='anyURI'>content?</>]
Igor:     required: WSDL processor has to understand the element 
          called "feature"
Gudge:    why don't we just have type?
[Proposal now: 
          <wsdl:feature uri="anyURI" required="boolean" />
          <wsdl:propertyConstraint uri="anyURI" type="QName" />
          <wsdl:propertyShortcutConstraint uri='anyURI'>
[shortcut is still an issue]
Glen:     feature makes sense only on portType and portType binding
[Gudge:   rough draft is at http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-fandp.xml]
Igor:     why property on port?
Amy:      fault address as a property. But it is cleaner if property 
          appears only on the binding tree 
Jonathan: strawpoll: remove property from port or not?
          8 in favor of having property on port
          3 to take it out
[GlenD:   <wsdl:service>
              <wsdl:property> <-- allow this? -->
            that was the poll]
[Marsh:   <wsdl:portType>
            <wsdl:feature />*
            <wsdl:property />*
              <wsdl:feature />*
              <wsdl:property />*
            <wsdl:property />*
              <wsdl:property />*
              <wsdl:property />*
Glen:     precedence of property: the most specific wins
Jonathan: question on complex content: disallow complex content 
          for properties or just disallow the shortcut?
[Answer:   Just disallow the shortcut.]
[plh-lap: <wsdl:propertyValue uri='anyURI'>content?</wsdl:propertyValue>
          <wsdl:propertyConstraint uri='anyURI' type='QName'/>
          <wsdl:feature uri='anyURI' required='boolean'/>
          any change?
          propertyValue and propertyConstraint are exclusive for a given 
          <wsdl:property uri='anyURI'
            <wsdl:constraint>QName (XML Schema type)</wsdl:constraint>
Gudge:    having two elements that refer to the same thing seems weired...
[plh-lap: (Gudge)
          <wsdl:property uri='anyURI'>
            <wsdl:constraint type='QName' />
Umit:     this is extensibility for the "plugability" of the spec
Lily:     any way to say a value is optional?
Glen:     look in the feature/property spec
[value and constraint are exclusive]
[plh-lap: <!ELEMENT property (value | constraint)>
          wsdl: or theExtensibilityNamespaceforPropertiesAndFeatures: ?]
[ericP:   can you know which feature will use a particular property?
          ie, if you have two features, would the properties be bound 
          to one or the other?]
[plh-lap: ericP, looking at the spec of the feature yes, but not looking 
          at the WSDL]
[ericP:   so the requiredness comes from the feature spec]
[plh-lap: ericP: that's correct, if the processor knows the feature, 
          the processor will look for the property.]
[ericP:   so that leaves them all required in that WSDL core libs will 
          need to preserve them for any feature that may need them.]
Glen:     you set a property without using a feature
Jacek:    the bindings' (soap:modules' etc.) specs have to say which 
          features are implemented in that binding (module etc.)
Jonathan: so the advantage of putting P&F into extension namespace is 
          that a processor can barf if it doesn't know P&F?
Igor:     features might just be hints 
Jacek:    I think the advantage is that simple WSDL processors needn't 
          know P&F and be simpler.
Glen:     tradeoff between having the feature stuff in the core and in 
          an extension
Igor:     Advantage if not part of the core. Then WSDL processor that 
          does not know about properties could still process the WSDL
David:    no point in doing it if it is not part of the core
Jeff:     agrees, if it would match the original proposition
Jonathan: puts an implication on future specs: they have to be 
          feature/property compliant
Gudge:    this takes us back to where we were in Virginia...
Jonathan: strawpoll: have this in the WSDL namespace or another NS?
[with phone votes: 11:4 (WSDL NS vs. other NS)]
Jonathan: Objections?

15:20 Break
15:40 Remove binding?
    - Gudge's "proposal" [3]

  [3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0115.html

(Remove binding topic)
... it was an interesting idea, but won't gonna fly...

15:50 7 MEP Review
    - Spec changes [4] and MEP spec [5].  Discussion starts at [6].
      Note that the chair was unable to pick up succinct explanations 
      of possible issues from the wide-ranging thread.  Assistance 
      from the participants in the thread is welcomed!
    - Names instead of numbers [7]
    - Operation content model issue [8]

  [4] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html?rev=
  [6] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0052.html
  [7] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0077.html
  [8] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0121.html

Two things we are reviewing:
  1. changes to part 1 of the spec
  2. list of 7 MEPs

Amy:      MEP 7 Problem: complex content model
[alewis:  OUT, ( (IN, oFault?) | iFault)*]
Amy:      major objection: a fault should only occur when the published 
          interface is violated.
[alewis:  OUT, (IN, oFault?)*]
Jacek:    2 kinds of faults: infrastructure (out of mem, etc.) and app 
Jacek:    MEP 7 is about infrastructure faults
[alewis:  OUT, IN*]
[Amy disagrees]
[alewis:  OUT, (IN, oFault?)*]
Amy:      response to input message of the client
Jacek:    mustUnderstand faults are an artifact of SOAP and must not 
          be described by the application
[sanjiva: when its appropriate, I'd appreciate if someone could 
          explain "infault" to me]
[Gudge:   faults that are inbound to the service. outfault is the 
[sanjiva: What does that mean? Why would a service indicate it 
          accepts incoming faults?]
Jacek:    in WSDL at port type level the assumtion that any message 
          can fault is not good. Amy agreed that MEP 7 is supposed to 
          represent solicit-response
Tom:      MEP 7 is different to all others because of multicast 
[Jacek:   out, (in || ifault)*]
Jacek:    suggesting that no app level fault can occur
Jeff:     is it our intention that we want 7 MEP in the spec and 
          processors need to know them? or do we want to describe 
          them as extensions?
[Gudge about to present "an intersting MEP"]
[plh-lap: MEPs -> http://www.w3.org/2003/01/meps.txt ]
Jonathan: MEP 7 is controversial
Sanjiva:  what about the other 6?

Gudge starts
[dbooth: Here are the 7 proposed MEPs: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-meps.html]
Gudge:    data service item (MEP 2)
[plh-lap: MEP 2 is IN, (OUT | OFAULT)]
Tom:      the good MEP
Gudge:    but now consider multicast
          Client view: sends out-msg, receives in-msg
          but client can receive in-msg that was triggered by 
          another client.  Is this case covered by MEP 2?
          Same port type for the unicast and multi-cast binding
[...dispute on the abstractness of bindings...]
David:    MEP needs to identify the node parts 
Jonathan: stop here. Continue the discussion in the morning

16:30 QA with Karl Dubost.
    - Spec writing guidelines (esp. extensibility) [9]

  [9] http://www.w3.org/QA/WG/2003/01/qaframe-spec/#Gd-extensions

Karl:     7 docs WSDL should review
[dbooth: http://www.w3.org/QA/]
[dbooth: http://www.w3.org/QA/WG/2003/01/qaframe-ops-checklist-20030129.html]
Karl:     operational guidelines, specification guidelines, test 
          guidelines.  Prioritized checkpoints ; not all of them 
          may always apply.  We will not do the QA job for you.
WS-Desc group: ooohhh
Jonathan: what about conformance of the WG specs to the QA spec?
Karl:     Don't know yet. Add to the charter that you need to 
          develop a test suite; benefit: helps to get the spec 
          right. Important to have a QA contact in the WG.
Jonathan: OP guidelines: chair and team contact. Spec 
          guidelines: editors. Test guidelines: ?
Philippe: WSDL test suite is chartered
Arthur:   we should have a normative schema for WSDL
Jonathan: ... a correct schema for WSDL
Arthur:   better a normative schema than a normative prose
David:    how to tie a (normative) schema to the spec?  Mark those 
          parts of the spec that are normative, if they cannot be 
          expressed in the schema
Jonathan: Editors willing to put in the markup?
[Gudge agrees]
ACTION:   editors to discuss normative markup question and come 
          back with a strategy
ACTION:   Jonathan to name a QA contact for the WG
Karl:     we do not encourage the groups to use extensions, but 
          recognise that they are sometimes necessary
Gudge:    given that XML is the *extensible* ML, I don't believe 
          in this statement...
ACTION:   editors to review the specification guidelines by 18th 
          of March

17:30 Adjourn
Received on Wednesday, 5 March 2003 15:31:11 UTC

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