Lists Home |
Date Index |
- From: "Roger L. Costello" <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 07 Nov 2000 07:31:23 -0500
Very good points Paul (and welcome back!)
You first design suggestion is to keep no-namespace schemas small, so
that schemas which wish to use the Chameleon components in the
no-namespace schema will not get a lot of unwanted components.
Good point. Since the Chameleon components are context (namespace)
independent, there is no reason for creating no-namespace schemas with
lots of components. Actually, now that you bring it up, I think that
the Chameleon design implicitly suggests lots of small no-namespace
schemas rather than a few, big no-namespace schemas.
One of the things that you said was:
> This is also an argument for using more local
> name scoping - if my main (namespaced) schema uses mainly local names,
> I am less likely to get clashes by including a no-namespace schema.
That's one way to deal with the namespace collision problem. That
approach, however, can really inhibit your "style" don't you think? I
think that a more flexible approach is the one that was discussed
yesterday - create proxy namespaced schemas. Each proxy namespaced
schema <include>s a no-namespace schema. The main schema then <import>s
the proxy schemas (rather than directly <include>ing the no-namespace
schemas). What do you think of that approach?
Your point about the no-reference limitation on Chameleon components is
well taken. I think that the bottom line is use the Chameleon design
wherever possible. /Roger
Paul Spencer wrote:
> As usual, I am getting behind on this, but I have been catching up today.
> I hit the exact problem that you have been referring to here about four
> months ago, and the Chameleon design was my preferred option. However, I
> don't think the limitations of this design can be brushed under the carpet.
> 1. Name Clashes
> When I use chameleon components, I feel that I should know what components I
> am using, and so avoid namespace clashes. However, because I have to use
> <include> rather than <import>, I get *all* the names in the document I am
> including into my namespace, even if I only wish to re-use one definition.
> As a minimum, we therefore need a guideline that we keep chameleon schemas
> small and focused. For example, rather than a single schema for the whole of
> Government (my own area of work), we would use a "name and address" schema,
> an "identifier" schema etc. This is also an argument for using more local
> name scoping - if my main (namespaced) schema uses mainly local names, I am
> less likely to get clashes by including a no-namespace schema. Of course, I
> might include two ...
> 2. Inability to use local references
> Again, a real handicap. For UK Government, we currently have three types of
> address, UK geographical, UK postal, and Overseas postal. Each of these
> shares some simple data types. I will have to redefine these types each time
> I use them, rather than have shared definitions.
> I wish I had an answer to these, since the management of namespaces is so
> key to the real-life use of XML Schema. Unfortunately, it looks like we have
> to live with these limitations.
> Paul Spencer
> Author: XML Design and Implementation (Wrox Press)
> Co-author: Beginning XML (Wrox Press)
> Boynings Consulting - Delivering XML to industry and government