Javi,
It's always good to know what OGC is doing and try to learn from their experience. However, they are not the only ones working with XML Schemas. And if you look at other groups you'll see that almost everyone uses either version numbers or dates in the namespace (just look at the namespaces declared in the <schema> element of tapir.xsd).
I know that "namespaces are not intended to solve crashes among semantics", but they do provide a way to say that ns1:myelement is fundamentally different than ns2:myelement, that was my point. I'm not sure if the example I gave was a good one - of course I wouldn't like to see this kind of difference between two TAPIR versions. It was just an example.
Yes, you can't validate a document without having the schema. But you could have the schema for some other reason without needing to read it from the schemaLocation. Actually I don't think it's safe to always trust the schemaLocation of documents (it should be possible to try to feed an application with an "alien" document that has a known namespace pointing to a fake schemaLocation... not sure how far this could go).
-Namespaces only change when there is a backwards compatibility problem. -We add the version attribute to the schema so that we can keep track of different versions.
Agreed. But when time comes, we just need to clearly define what kind of changes would mean breaking backwards compatibility.
And I would include (I dont know if you agree on this) -Use 2 numbers in the namespace and 3 in the version and keep them consistent.
Could be one or more numbers, or dates... it's just an identifier. I'll be happy with any of the available options, even the current one.
Regards, -- Renato