RE: [XML Schema 1.1] What problem is this solving: the ability to define multiple targetNamespaces in a single schema

I think CMSMcQ must have got out of bed the wrong side this morning - his
note contains the answer, but it's so buried in ramblings and musings that
you might have trouble finding it!

The problem this facility is solving is the use case where you want to
customize an industry-standard schema such as FpML for local use, by
defining types that restrict the types in the base schema. It's not nice to
define your types in the FpML namespace, because it's not your namespace. So
you ought to define your types in your own namespace. But for your
restriction to be a valid restriction, it has to contain element particles
in the FpML namespace. So this facilitity is allowing the elements in the
content model of a type, even though they are local element declarations, to
be in a different namespace from the containing type.

I was all for generalizing this to allow any component to be in any
namespace, with the targetNamespace of the schema document acting only as a
default. But there's a school in the WG that wants to avoid providing syntax
that can be abused to create bad designs, and on this occasion they won the
day, resulting in a facility that (as CMSMcQ points out) is highly
constrained so that it only solves this one particular use case.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay 

 

> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Costello, Roger L.
> Sent: 21 July 2009 00:42
> To: xmlschema-dev@w3.org
> Subject: [XML Schema 1.1] What problem is this solving: the 
> ability to define multiple targetNamespaces in a single schema
> 
> 
> Hi Folks,
> 
> In XSD 1.1 a schema can have multiple targetNamespaces. 
> Presumably this capability was introduced to solve a problem. 
> What problem is it solving?
> 
> /Roger