No - its not merely the identity issue. 
It’s the processing issue. 
A processors will maintain a cache of schema component definitions and
declarations and associate it with a namespace. 
The processing rules in the XML Schema spec do not require that a processor
load the schema fresh if a new document comes in with the same namespace. 
So if the new document is actually using a different schema (even if the
namespace is the same) then processing will fail. 
The only way to ensure safe processing (i.e. that respects *all* of the
processing straegies allowed for in the XML Schema spec) is to be scrupulous
about changing namespace if the schema changes. 
In many cases that is most easily handled by including a version identifier
in the namespace. 

Because of all this, the XML Schema processing rules effectively imply that
the target namespace is the schema identifier. 

--------------------------------------------------------
Simon Cox

European Commission, Joint Research Centre, 
Institute for Environment and Sustainability, 
Spatial Data Infrastructures Unit, TP 262 
Via E. Fermi, 2749, I-21027 Ispra (VA), Italy 
Tel: +39 0332 78 3652
Fax: +39 0332 78 6325
mailto:simon.cox@j... 
http://ies.jrc.ec.europa.eu/simon-cox 

SDI Unit: http://sdi.jrc.ec.europa.eu/ 
IES Institute: http://ies.jrc.ec.europa.eu/
JRC: http://www.jrc.ec.europa.eu/
--------------------------------------------------------

-----Original Message-----
From: Andrew Welch [mailto:andrew.j.welch@g...] 
Sent: Wednesday, 2 September 2009 19:18
To: Simon Cox
Cc: noah_mendelsohn@u...; Tsao, Scott; G. Ken Holman; Henry S.
Thompson; xmlschema-dev@w...; ekimber
Subject: Re: Best Practices for Establishing Namespace Name

2009/9/2 Simon Cox <simon.cox@j...>:
>  Andrew Welch wrote
>> use a version attribute to distinguish the versions
>
> Where?

Typically on the root element, but it could go anywhere that's suitable.

> The issue was that elements with the same name were defined 
> differently in both GML 2.0 and GML 3.0, But they had the same target 
> namespace. The differences were subtle - technical rather than 
> conceptual - but real as far as a validating processor is concerned. 
> The XML namespace is to all practical intents and purposes the 
> designated identifier for 'the schema' and we had the same identifier 
> for different things. Chaos ensues.

Between versions the content model of elements will change, but that doesn't
mean you need a different namespace... Incompatible changes are actually
easier than supporting backwards compatibility, instead of detecting the
version and using the right xsd and corresponding parsing code, you simply
reject anything that fails validation for that version.

Anyway, it's interesting that you say the namespace is (to all intents ands
purposes) the identifier for the schema, perhaps that's where the problem
is... the namespace value itself has started to mean something, when its
meant to mean nothing.

Everyone seems to have different opinions on this, and I think Ive asked in
the past if anyone has a best practices guide which didnt attract too many
confident replies, but at the moment for me its simply "namespace that won't
ever change, version attribute" : )




--
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/