Doug Bunting wrote:
> Tom,
>
> Yes, this would provide better extensibility. The immediate question
> is where we need to allow such extensibility? I doubt every element
> needs this support though it is definitely necessary for more than
> just our top-level SOAP headers. I see little use for this in (for
> example), the MessageId and SequenceNum elements but they can be
> defined easily without relying on EmptyType.
>
> To go a bit further, I would define three general element types for
> use throughout the schema, EmptyType, ExtensibleType and HeaderType
> (or something similar), and use those as appropriate. EmptyType
> should be the type of our simplest "pseudo Boolean" elements and never
> extended. HeaderType would be the base for our four SOAP header
> elements. ExtensibleType would be the base of all other elements which
> are extensible (it could also be the base for HeaderType); elements
> which are not extensible or empty would be defined without an explicit
> base type.
The latest proposed schema I posted has two types, headerBaseType and
extensibleBaseType.
There is no base type for simple types in this schema.
Tom Rutt
>
>
> Less importantly and more generally (about the schema as a whole and a
> long standing question I have forgotten to ask), this model puts all
> extension content (new elements) at the beginning of the WSRM
> elements. This is counter-intuitive though I realise it comes from
> the use of schema type extensions rather than consistent placement of
> xsd:any at the end of every "interesting" complex type. For example,
> an extended MessageHeader would (today) appear as:
>
> <wsrm:MessageHeader soap:mustUnderstand="1">
> <foo:bar letsGoToTheBar="yeah" />
> <wsrm:MessageId ... />
> <wsrm:ExpiryTime ... />
> <wsrm:ReplyPattern ... />
> </wsrm:MessageHeader>
>
> rather than something that appears extended:
>
> <wsrm:MessageHeader soap:mustUnderstand="1">
> <wsrm:MessageId ... />
> <wsrm:ExpiryTime ... />
> <wsrm:ReplyPattern ... />
> <foo:bar letsGoToTheBar="yeah" />
> </wsrm:MessageHeader>
>
> Should we change our choice here?
>
> This also reminds me of another schema nit: Why is the existing
> extensible type (the one with the required soap:mustUnderstand) named
> wsrm:RmBaseType, I thought we nuked all of the "Rm" prefixes? I
> purposefully chose HeaderType above to work around this complaint.
>
> thanx,
> doug
>
> On 20-Feb-04 12:09, Tom Rutt wrote:
>
>> Would the following change to the empy type provide better
>> extensibility for the protocol?
>>
>> <xsd:complexType name="EmptyType">
>> <xsd:sequence>
>> <xsd:any namespace="##other" processContents="lax"
>> minOccurs="0" maxOccurs="unbounded"/>
>> </xsd:sequence>
>> <xsd:anyAttribute namespace="##other" processContents="lax"/>
>> </xsd:complexType>
>>
>> The above prosal adds extensible attributes and elements , without
>> the soap must understand attribute which is there for header elements.
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>
>
--
----------------------------------------------------
Tom Rutt email: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
