Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi Folks, I need your feedback on the schema design approach which I have been calling the "Chameleon Namespace design". Recall that with this design approach you do not assign a targetNamespace to your schemas. The schema components are thus in "no-namespace". When another schema <include>s the no-namespace components, the components take on the namespace of the schema doing the <include> (hence, the name "Chameleon"). I am really excited about this design approach. I see many benefits. It is such a novel and exciting design strategy. I fear, however, that in my exuberance I may have blinders on and may not be seeing the disadvantages. I need you to help open my eyes to any downsides. Below I have listed what I perceive to be the benefits of this approach: - The components in the schemas with no targetNamespace (the "no-namespace" components) are infinitely malleable - they are able to take on the namespace of any schema that <include>s or <redefine>s them (the Chameleon effect). - The no-namespace components can be reused by any schema. - The no-namespace components can assume many different semantics. For each schema that <include>s them, they can take on a new role and new semantics. - The no-namespace components can be <redefine>d by any schema, regardless of the schema's targetNamespace. - The no-namespace components are not "fenced in" by a namespace. They are free, independent, and with no boundaries. They owe their allegiance to no namespace! Pretty powerful design, aye? It enables a whole new breed of reusable components. As excited as I am about this design approach, I am also struggling with it because it really strikes at the heart of namespaces, and calls into question their value. At minimum, it relegates namespaces to a lesser (or different) role. What are your thoughts on this design approach? /Roger
|
