Property component's dependency on XML Schema

It occurred to me that the definition of the Property component [1] in Part 1
ties it pretty strongly to XML Schema as well as an infoset-based view of
the world. Since the general trend has been to remove such dependencies and
allow more general type systems to be used, it behooves the WG to fix this
anomaly.

The Property component contains, among others, the following two properties:

- {value constraint} REQUIRED. A type definition constraining the value of the property.
- {value} OPTIONAL. The value of the property.

I see (at least) three issues raised by those two lines:

(a) This is the only reference to a "type definition" (component?) as a value
of a property. In the corresponding mapping section (2.8.3), the spec talks
about "the type referred to by the value of the constraint EII", but there
is no definition of a {type definitions} property on the Definitions component
to parallel {element declarations}.

(b) The definition of the optional {value} property doesn't mention its type.
Is it integers, element information items, toy soldiers or omelettes? (In case
you're in doubt, it's the second alternative, EIIs.)

(c) Since the {value constraint} property is required, the Property component
is effectively tied to XML Schema, i.e. if somebody were to define a property
whose values range over something other than element information items, they
would still need to specify a (presumably bogus) type declaration as the
value of this property.

Additionally,

(d) In section 2.8.3, the mapping for {value constraint} maps a value,
specified using the <value>...</value> syntax to "an anonymous type,
whose base type is xs:anyType, with a single enumeration facet whose
value is the type of the value of the value AII". This doesn't work
any more, since the WG decided to allow complex property values and
there is no concept of enumerations, or facets for that matter, in
complex type definitions.

Here's a proposal, addressing issues (a)-(d) in order:

(1) Add a {type definitions} property to the Definitions component and spell
out the rules on how to populate it, just as we do for {element declarations}.

(2) Specify that the type of the {value} property is an element information
item per the XML Infoset spec.

(3) Make the {value constraint} property optional and add text saying that
if a type system not based on the XML infoset is in use, then additional
properties need to be added to the Property component to associate such
types with the constraint of a property; similarly for the property value.
(This text would be analogous to that employed by the description of
the Message Reference component in section 2.5.1).

(4) Get rid of the offending mapping rule: if a value is specified,
then it's used to fill in the {value} property and the {value 
constraint} property is set to a unique value (a token), e.g. #value.
This is analogous to the use of #empty and #any tokens in the Message
Reference component.

Roberto

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html%3B0charset=utf-8#Property

Received on Tuesday, 20 July 2004 19:37:33 UTC