Some notes on Part 1

While working on some editorial action items for part 1, I ran into a few
glitches.

1. There was a conflict between the definition of the {safety} property and
its mapping. The definition said that the property is optional and has
"false" as a default value. The mapping said that, missing a @safe attribute,
the property is assigned the value "false". So effectively the property
is never going to be absent. Consequently, I marked it as REQUIRED and
removed the default value of "false" from the property definition.
Let me know if there are any objections to this change.

2. I added a definition of equivalence for list types (element-wise
equivalence, that is). This causes some funny behavior for {styles},
because the latter is defined as being a list for which the order of the
elements doesn't matter. Then you get into the odd situation of two
operation components

C1:  {styles} = [A, B]
C2:  {styles} = [B, A]

which are not equivalent as components (per our definition) but are
semantically equivalent. I'd like to propose then that we turn the
{styles} property into a "set of URIs", so that the two kinds of
equivalence will be in agreement.

3. The {message label} property of the Fault Reference is currently
marked as OPTIONAL. The mapping rules specify how to fill it in when
there is no @messageLabel attribute on a in/out fault and there is
only one possible value for it, but then they say "otherwise empty".
I have a hard time figuring out what it means to have a Fault Reference
component that doesn't specify a message label. Surely, we can leave
the @messageLabel attribute as optional and make the {messageLevel}
property required without any negative effects.

4. The {extended interfaces} property of the Interface component
was the only set-valued property that was OPTIONAL, because the
mapping text explicitely used the clause "otherwise empty". For
consistency, I made it required and removed that clause.

5. (A follow up to 4.) In the description of the component model,
we follow XML Schema's precedent and differentiate between empty
sets and an "empty" (i.e. missing) set-valued property. This
causes some ugliness, because all set-valued properties (e.g.
{interfaces} of the Definitions component) are marked as REQUIRED
but allow the empty set as a value. This may lead some readers
to think that a WSDL interface must contain at least one interface.
I haven't found any place where equating an absent set-valued property
with one whose value is the empty set would wreak havoc, so I'd
like to propose that we state that formally and then mark all
set-valued properties that accept the empty set as a value
(all of them right now) as OPTIONAL. The only exception would be
cases in which the presence of a property is itself used as a flag;
two workarounds are possible then: (1) define an extra property
with a token as a value, the way we do for {message content model}
of the Message Reference component, or (2) mark the property
as REQUIRED and gladly accept an empty set as a value (I think
that's what {rpc-signature} does).

Roberto

Received on Tuesday, 13 July 2004 21:23:24 UTC