[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Schemas: Best Practices
Hi Folks, Last week I asked for people to help me understand the limitations of using the Chameleon Namespace design approach. Recall that with this design approach you create schemas with no namespace so that those Chameleon components can incorporate into many different namespaces. Toivo, Ron, and Curt came up with two limitations of this design approach: (I will discuss the first limitation in this message. The second limitation will be discussed in a follow-up message.) a. Name collision. When you use Chameleon components those components become part of the namespace, just as though you had typed the element declarations and type definitions inline. If you <include> multiple no-namespace schemas then there is an increasing risk of namespace collisions. In fact, you may end up not being able to use some of the no-namespace schemas because their use results in name collisions with other Chameleon components. To see this, consider this example: Example. Suppose that there are two schemas which create Chameleon components: 1.xsd A B 2.xsd A C Schema 1 creates no-namespace elements A and B. Schema 2 creates no-namespace elements A, and C. Now if schema 3 <include>s these two schemas there will be a name collision: 3.xsd targetNamespace="http://www.example.org" <include schemaLocation="1.xsd"/> <include schemaLocation="2.xsd"/> This schema has a name collision - A is defined twice. Namespaces provide a way to avoid such collisions. Above, if instead those components resided in different namespaces then 3.xsd could have <import>ed them and there would be no name collisions. [You can have the same element/type name if the element/type is in different namespaces.] My response: There is a very simple solution to the namespace collision problem: <include> each schema containing Chameleon components into a separate schema that has a namespace and then <import> those two schemas into the main schema: <!-- Put the 1.xsd Chameleon components into this namespace --> 1-new.xsd targetNamespace="http://www.foo.org" <include schemaLocation="1.xsd"/> <!-- Put the 2.xsd Chameleon components into a different namespace --> 2-new.xsd targetNamespace="http://www.bar.org" <include schemaLocation="2.xsd"/> <!-- Import the components, which are now in namespaces --> main.xsd targetNamespace="http://www.main.org" <import namespace="http://www.foo.org" schemaLocation="1-new.xsd"/> <import namespace="http://www.bar.org" schemaLocation="2-new.xsd"/> With this approach we avoid name collisions. We also get the ability to customize the components with <redefine>. Contrast the above two-step process with this one-step process where we put the components in a namespace from the very beginning: 1-fixed.xsd targetNamespace="http://www.foo.org" A B 2-fixed.xsd targetNamespace="http://www.boo.org" A C main.xsd targetNamespace="http://www.main.org" <import namespace="http://www.foo.org" schemaLocation="1-fixed.xsd"/> <import namespace="http://www.bar.org" schemaLocation="2-fixed.xsd"/> This achieves the same result as the above two-step version. In this example, the components are not Chameleon. Instead, A, B, and C were placed into a namespace from the very beginning of their life. If main.xsd wants to <redefine> any of the elements it cannot. It must either take it or leave it. I like the Chameleon approach even more! Rather than starting a component's life out in a rigid, static, fixed namespace, the Chameleon approach frees them so that applications can decide on a domain (namespace) for the components. Furthermore, applications can refine/customize the Chameleon components. This approach requires an extra step but in return it gives you a lot of flexibility. Wow! What are your thoughts on this? /Roger
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|