On 12-03-14 1:54 PM, "David Francis Buhler" <davidbuh...@gmail.com> wrote:
>Omitting the xmlns attributes in MXML would make MXML valid XML, it
>just wouldn't prevent namespace collisions (because there is no
>namespace prefix).
Correct. XML NameSpaces are perhaps one of the most misunderstood
mechanisms on the planet. You can have perfectly legal XML like this:
<!--I am not typing the XML PI every time to demonstrate-->
<foo>
<bar/>
</foo>
But if you have a large schema and there are different elements with the
same name, a parser's handler will not know how to differentiate the two.
<foo>
<bar>This bar is meant for a widget</bar>
<struct>
<bah>
<bar>This is some other bar</bar>
</bah>
</struct>
<foo>
Because the designers of MXML wanted to allow developers to build custom
components, the namespaces are considered a mandatory piece of the MXML to
avoid collisions (elements in different classes with the same name) in the
event those building custom components accidentally used names used by
MXML (this still throws the odd error WRT the SDK and named methods like
"close()".
Consider an XML fragment like this:
<?xml version="1.0"?>
<document xmlns:foo="http://www.value1.com"; >
<!--If you do a "getNamespace()" on the following element, it will
return the value of "www.value1.com"-->
<foo:name>Duane Nickull</foo:name>
<InnerElement xmlns:foo="http://www.value2.com";><name/>
<!-- if you do the same "getNamespace()" operation on the next
line, the value will be www.value2.com-->
<foo:name>Duane Nickull</foo:name>
</InnerElement>
</document>
Parsers always resort to the inner most lexically
scoped namespace. In any event, you would need a conflict of both the
namespace itself AND the namespace value before any harm was done.
I vote to leave MXML as it is from an XML namespace standpoint.
I would suggest one minor fix -> CDATA declarations for anything like CSS
styles that have even the remote possibility of having XML illegal
characters in them one day.
Duane
>
