It doesn't really work that way. Especially not since Flex 4. There was an attempt at having no namespace at all and to assume mx namespace to be the default. But since in Flex 4 there are a lot of components in the SDK that come in two flowers, but with same names, but not only that, the code generation has changed, you must have the namespace specified on the top-level component tag.
Now, what is the use of the namespace in MXML: you should probably first find all the *-manifest.xml files in the framework folder of the SDK to see where it comes from. So, namespace maps arbitrary components under the same "package". I can imagine this was a more of an forced move, because, originally, MXML would understand namespaces to be the package names. For example: <flash:Sprite xmlns:flash="flash.display.*"/> Now imagine an average MXML template - it may use components from tens of different packages, so your top-level tag would looks something like: <flex:Application xmlns:flex="mx.core.*" xmlns:bindings="mx.bindings.*" xmlns:utils="mx.utils.*" . . . > . . . </flex:Application> That's another... doubtingly useful feature of MXML design... while in AS3 you only need to import into scope once, and you don't need to mention the source, unless there is ambiguity, XML format doesn't allow this kind of approach (why use XML for programming language templates is another tough question, I'm not trying to ask at the moment...) So, ultimately, that would be a step backwards to the situation, where you have to write the package and the imported class all the time. The compiler attribute `-namespace` came to rescue: so you can group classes into the same namespace regardless of their actual namespace/package. This is still not as good as normal AS3 way to deal with the problem, but it reduces the verbosity, so that's the reason to use it. So, if this problem was to be addressed, maybe it would be possible to add a compiler argument `-default-namespace` that would have to match a namespace from those available to the project and would be implied when resolving components. So you would only need to specify a namespace for the foreign code. This has it's downside as it might be too complex for an average user to configure and is prone to subtle errors - results of naming collisions. Best. Oleg
