[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Schemas: Best Practices - Chameleon design

• From: "Roger L. Costello" <costello@m...>
• To: xml-dev@l...
• 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.
> 
> Regards
> 
> Paul Spencer
> Author: XML Design and Implementation (Wrox Press)
> Co-author: Beginning XML (Wrox Press)
> Boynings Consulting - Delivering XML to industry and government
> http://www.boynings.co.uk/

• Follow-Ups:
  • Re: XML Schemas: Best Practices - Chameleon design
    • From: "Thomas B. Passin" <tpassin@h...>

• Prev by Date: Re: W3C XML Schema best practice : inclusions
• Next by Date: Re: XML Schemas: Best Practices - Chameleon design
• Previous by thread: Part 2: datatypes
• Next by thread: Re: XML Schemas: Best Practices - Chameleon design
• Index(es):
  • Date
  • Thread