Re: Property component's dependency on XML Schema

An addendum to the proposal. There is one more issue:

(e) In the syntax for the property component, we require exactly one of the
<constraint/> and <value/> EIIs to appear among the [children] of <property/>.
This prevents using a different type system to specify a property's value
or constraints.

The proposed fix is:

(5) Make both <constraint/> and <value/> optional.

Roberto


Roberto Chinnici wrote:
> 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 Wednesday, 21 July 2004 17:37:44 UTC