OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: XML Schemas: Best Practices - Chameleon design

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Spencer <paul.spencer@boynings.co.uk>
  • To: "Thomas B. Passin" <tpassin@home.com>,"Roger L. Costello" <costello@mitre.org>, xml-dev@lists.xml.org,ht@cogsci.ed.ac.uk
  • Date: Wed, 08 Nov 2000 09:24:51 +0000

Yes it *would* be a good thing if it worked. But as long as we have an
<include> rather than an <import> we run the risk of getting too much
rubbish that we don't want. I certainly expect my re-usable (chameleon)
schemas to grow as we develop our schema set over the next five years. Since
we anticipate growth rather than change in the chameleon schemas, I want
this to be safe for all existing schemas that are using the definitions in
the chameleon schema. But it isn't! Name collisions could suddenly appear in
"stable" schemas as the chameleon schema grows. So now we need much tighter
(and possibly impossible to manage) version control. Using proxy schemas
doesn't help me as I want the names to be in the "target" namespace.

Now I will disagree with Roger. He says that "As we saw above, the Chameleon
Namespace design approach has restrictions on how the no-namespace
components must be designed for them to be usable by other schemas. Namely,
they must not reference one another. The components must be decoupled (which
is a desirable trait)." I disagree that this is a desirable trait. I want
several complex data types to use a common simple type that I have defined.
"ZipCode" might be an example. Doing this seems to me to be a desirable
trait, but I can't with a nonamespace schema.

So with a large schema base, I am stuck.

I am not sure whether there are things we can do with
elementFormDefault="unqualified" that would help here. I would sure like
help to examine it. Does Henry T have a view? I think we are working here in
possibly the most important aspect of schema design at the moment since
bottoming out schema re-use is vital to any migration towards a semantic
web. Great stuff Roger and the rest of you!

Meanwhile, did my last message make the list? I realise Roger got it, but I
got a bounce from the mail server "550 <xml-dev@lists.xml.org>... Host
unknown Name server: smtp.elistx.com.: host not found)".

Paul Spencer
Author: XML Design and Implementation (Wrox Press)
Co-author: Beginning XML (Wrox Press)
Boynings Consulting - Delivering XML to industry and government

-----Original Message-----
From: Thomas B. Passin [mailto:tpassin@home.com]
Sent: 07 November 2000 14:04
To: Roger L. Costello; xml-dev@lists.xml.org
Subject: Re: XML Schemas: Best Practices - Chameleon design

Schema omponents, when included into a schema, take on the
parent schema's target namespace, if they are not already in
it or don't have one of their own.  This suddenly reminded
me of the new import syntax in Python (I don't know how many
other languages already have it too):

import spam as eggs

This lets you have your cake and eat it too - your
components can be referred to by any namespace you want.
Seems to me that this is very close to what Cameleon
provides.  This sounds like a GOOD THING to me.


Tom Passin


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS