RE: Extending Types

FWIW, sounds like a use case for typed wildcards [1] if they existed.

<xs:complexType name="MyMessageType">
    <xs:sequence>
        <xs:element name="Header">
            <xs:complexType>
                <xs:sequence>
                    <xs:element name="Who" type="xs:string"></xs:element>
                    <xs:element name="When" type="xs:string"></xs:element>
                </xs:sequence>
            </xs:complexType>
        </xs:element>
        <xs:any type="BaseBusinessContent"/>
    </xs:sequence>
</xs:complexType>

<xs:complexType name="BaseBusinessContent">
   <xs:sequence>
       <xs:element name="Code" type="xs:string"></xs:element>
       <xs:element name="Description" type="xs:string"></xs:element>
   </xs:sequence>
</xs:complexType>

xan

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=2866


-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Flavio Cordova
Sent: Tuesday, December 01, 2009 4:25 PM
To: xmlschema-dev@w3.org
Subject: Re: Extending Types

I may have found another way, although is not exactly what I'm looking for..

In definition.xsd

<xs:complexType name="MyMessageType">
    <xs:sequence>
        <xs:element name="Header">
            <xs:complexType>
                <xs:sequence>
                    <xs:element name="Who" type="xs:string"></xs:element>
                    <xs:element name="When" type="xs:string"></xs:element>
                </xs:sequence>
            </xs:complexType>
        </xs:element>
        <xs:element ref="AbstractBusinessContent"></xs:element>
    </xs:sequence>
</xs:complexType>

<xs:element name="AbstractBusinessContent" abstract="true"></xs:element>
<xs:element name="MyMsg" type="MyMessage"></xs:element>

Notice that I have create a reference element of MyMessage
(ref="AbstractBusinessContent") and defined this element as abstract
(although, "abstract" seems to be useless, it avoids that the user
could use this element in the XML).

Then in child.xsd:
<xs:include schemaLocation="definition.xsd"></xs:include>
<xs:complexType name="BusinessContent">
   <xs:sequence>
       <xs:element name="Code" type="xs:string"></xs:element>
       <xs:element name="Description" type="xs:string"></xs:element>
   </xs:sequence>
</xs:complexType>

<xs:element name="BusinessContent" type="BusinessContent"
substitutionGroup="AbstractBusinessContent"></xs:element>

Notice here that I just defined another complexType (BusinessContent)
and created an element using substituitionGroup. That means I could
use it instead of AbstractBusinessContent.

Why it's not perfect: Now I can't pre-define any content for BusinessContent...

I'm feeling much more comfortable, yet not satisfied... I mean, I can
solve my problem just setting GenericInformation a sibling of
BusinessContent, but I still think there should be a way to make
abstract types do the job.. :(


On Tue, Dec 1, 2009 at 5:27 PM, Flavio Cordova <flavio.cordova@gmail.com> wrote:
> You mean something like this ?
>
> <xs:complexType name="AbstractBusinessContentType"> <!-- No abstract
> attribute anymore -->
>   <xs:sequence>
>     <xs:group ref="BusinessContentGroup"></xs:group>
>   </xs:sequence>
> </xs:complexType>
>
> Then I leave definition.xsd with no definition for
> BusinessContentGroup and only define it in item.xsd, changing
> xs:redefine to xs:include, right ?
> That works but then the parent XSD becomes invalid, since the group
> isn't defined there, right ?
>
> I'm not comfortable with this solution (although I will use it if
> nothing betters comes up :D).. Is there any other ?
> I know it could sound a little picky, but I seems to me abstract
> should do the work and I'm just forgetting something...
>
>
>
>
> On Tue, Dec 1, 2009 at 5:00 PM, Michael Kay <mike@saxonica.com> wrote:
>>>
>>> Actually, in my case, I need to create a complexType that
>>> will be extended by other people, just overwriting (or
>>> "implementing") the BusinessContent tag.
>>
>> I think the simplest solution is a low-tech one: have your type refer to a
>> named model group called BusinessContentGroup which you define in a separate
>> schema document, which people can edit.
>>
>> OK that has disadvantages, for example it makes it difficult for different
>> extensions of the schema to coexist, but those disadvantages apply to nearly
>> all other techniques as well.
>>
>> Regards,
>>
>> Michael Kay
>> http://www.saxonica.com/
>> http://twitter.com/michaelhkay
>>
>>
>

Received on Wednesday, 2 December 2009 17:56:44 UTC