- From: <jim.murphy@pobox.com>
- Date: Mon, 13 Jan 2003 13:45:19 -0500
- To: <xmlschema-dev@w3.org>
Hi everyone, My sincere apologies if this issue has been dealt with on this list already but I haven't been able to track down a clear answer... I've reading a lot of Web Services related schemas these days that liberally apply the xsd:any to wildcard content models for future extensibility. If I understand it correctly, the intent is to provide a v1 schema that will be compatible with a v2 schema: <xsd:complexType name"version1> <xsd:sequence> <xsd:element name="foo" type="xsd:string" /> <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="##any" processContents="lax"/> </xsd:sequence> </xsd:complexType> will suffice for version 2: <xsd:complexType name = "version2"> <xsd:complexContent extension=" version1" <xsd:sequence> <xsd:element name="bar" type="xsd:integer" /> <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="##any" processContents="lax"/> </xsd:sequence> </xsd:complexContent> </xsd:complexType> Since the changes are additive I this is fine provided the original schema authors had the foresight to provide extensibility wildcards in the all the right places in the first version. But, it made my wonder why derivation by extension type compatibility isn't the default - so called or record width sub-typing? That way as long as I provide the essential elements/attributes described in the schema I'm alright and it's not an error if I happen to include more. I realize I bring an OO bias to XML so I was curious why this decision was made... Regards, Jim
Received on Monday, 13 January 2003 14:11:52 UTC