You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We get a namespace of xmlns="" in the BarElement definition. I was hoping to just not have an xmlns attribute, meaning that the definition of BarElement would pick up the default namespace (http://foo.example.com). In order to get that behavior I have to explicitly provide the uri. Is this the expected/intended behavior?
The text was updated successfully, but these errors were encountered:
I'd argue that XML doesn't mandate anything about how are API works. But the parallel with XML is that if we don't specify and xmlns, we pick up the current default. Whereas our API results in not specifying an xmlns yielding xmlns="". But if were to implement things as I suggested, it would mean that the actual xmlns of an element wouldn't be known until the default namespace was known, that is to say that if you make some nodes and move them around, the actual NS could change. I can see arguments for both kinds of behaviors, but the current one seems a bit unintuitive to me.
Currently, if we do:
We get a namespace of xmlns="" in the BarElement definition. I was hoping to just not have an xmlns attribute, meaning that the definition of BarElement would pick up the default namespace (http://foo.example.com). In order to get that behavior I have to explicitly provide the uri. Is this the expected/intended behavior?
The text was updated successfully, but these errors were encountered: