- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 5 Mar 2003 12:31:03 -0800
- To: <www-ws-desc@w3.org>
--------------------------------------------------------
Monday 3 March
--------------------------------------------------------
09:00 Introductions and logistics
Present:
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
Phone:
Allen Brookes Rogue Wave Software
Steve Lind AT&T
Lily Liu webMethods
Jean-Jacques Moreau Canon
Sanjiva Weerawarana IBM
Observers:
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
Regrets:
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:
<portType>
<feature url="securechannel" required=true/>
</portType>
<soapBinding>
<soapmodule uri="securemodule"/>
</soapBinding>
[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
binding
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
features
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
features?
[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
binding
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>
<wsdll:constraint>QName</wsdll:constraint>
</wsdl:property>]
[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:value>content</wsdl:value>
<wsdl:constraint>Qname</wsdl:constraint>
<wsdl:property>
<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)"?>
content?
</wsdl:property>
[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 ....
</restriction>
</complexType>
then:
<property uri="http://foo" type="blah:t"
xmlns:blah="http://blah"/>
OR
<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
properties
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
type
[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'>
content?
</wsdl:propertyShortcutConstraint>]
[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:port>
<wsdl:property> <-- allow this? -->
</wsdl:port>
</wsdl:service>
that was the poll]
[Marsh: <wsdl:portType>
<wsdl:feature />*
<wsdl:property />*
<wsdl:operation>
<wsdl:feature />*
<wsdl:property />*
</wsdl:operation>*
</wsdl:portType>
<wsdl:binding>
<wsdl:property />*
<wsdl:operation>
<wsdl:property />*
</wsdl:operation>*
</wsdl:binding>
<wsdl:service>
<wsdl:port>
<wsdl:property />*
</wsdl:port>
</wsdl:service>]
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
URI
<wsdl:property uri='anyURI'
<wsdl:value>content</wsdl:value>
<wsdl:constraint>QName (XML Schema type)</wsdl:constraint>
</wsdl:property>]
Gudge: having two elements that refer to the same thing seems weired...
[plh-lap: (Gudge)
<wsdl:property uri='anyURI'>
<wsdl:value>content</wsdl:value>
<wsdl:constraint type='QName' />
</wsdl:property>]
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?
[none]
--------------------------------------------------------
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=1.21.2.1&content-type=text/html
[5]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-meps.html
[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
faults
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
opposite]
[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
response
[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