- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Wed, 05 Mar 2003 09:31:40 -0500
- To: Rich Salz <rsalz@datapower.com>
- Cc: Jonathan Marsh <jmarsh@microsoft.com>, "xml-dist-app@w3.org" <xml-dist-app@w3.org>
On Sunday, Mar 2, 2003, at 21:32 America/Boston, Rich Salz wrote:
>
> The definitive tone of Don's message made me go back and re-read the
> proposal. I still think I'm right. If only "literal" is supported,
> than
> the message schema must exactly describe the message: no multiref
> strings,
> etc., unless explicit encoded into the schema. Is that correct?
>
Yes, you are indeed correct.
> If I have an operation
> int foo(const char* a, const char* b)
> then using SOAP encoding, the body would look like
> <SOAP:Body>
> <foo xmlns="....">
> <a href="#b"/>
> <b>cloned string</b>
> </foo>
>
> But the schema would look like foo as a complex element with
> sub-elements
> a and b as xsd:string.
>
Note that the SOAP encoding schema includes a set of simple types for
just this purpose, e.g.
<xs:attributeGroup name="commonAttributes" >
<xs:annotation>
<xs:documentation>
Attributes common to all elements that function as accessors or
represent independent (multi-ref) values. The ref attribute is
intended to be used in a manner like CONREF. That is, the
element
content should be empty iff the ref attribute appears
</xs:documentation>
</xs:annotation>
<xs:attribute ref="tns:id" />
<xs:attribute ref="tns:ref" />
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:attributeGroup>
<xs:attribute name="id" type="xs:ID" />
<xs:attribute name="ref" type="xs:IDREF" />
<xs:element name="string" type="tns:string" />
<xs:complexType name="string" >
<xs:simpleContent>
<xs:extension base="xs:string" >
<xs:attributeGroup ref="tns:commonAttributes" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
So for simple types you can use the SOAP encoding variants. For complex
types you can re-use the attributeGroup. Not a perfect solution but
better than nothing.
Marc.
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Wednesday, 5 March 2003 09:31:49 UTC