CODEWITHSUNDEEP
xmlnamespaces
Samuel Toh
Samuel Toh

Reputation: 19228

Can a XML schema have mix and match of qualified and unqualified namespaces?

From what I know from W3school is that if the attribute "elementFormDefault" is set to unqualified on a XML schema then XML elements will not have prefixes. Can this be a problem if I have a schema that has unqualified element form set and am importing another schema?

Example: I have Schema A that imports Schema B's stuff. Then in a most unfortunate scenario Schema A has an element called "ItemName" in which Schema B also has one. And since we can't use prefix here, there is no easy way to distinguish both elements.

Is this a valid scenario?

if yes, how do I distinguish them?

And if yes, does that mean that a schema can have mix and match of elementFormDefault=qualified and unqualified namespaces living in it and not have potential element name clashes in them?

Thanks for your help!

Upvotes: 1

Views: 485

Answers (2)

Michael Kay
Michael Kay

Reputation: 163272

To start with a direct answer to your question: elementFormDefault is what it says, it is simply a default for the "form" attribute on element declarations, and you can set the form attribute on individual declarations to different values if you want.

But I've never seen anyone do it, and there are probably good reasons for that.

But now, reading your question more carefully, there are several wrong assumptions in it.

Firstly, elementFormDefault applies to a single schema document, not to the whole schema. In particular, it does not affect an imported schema document.

Secondly, you say that if you use elementFormDefault=unqualified, then elements will not have prefixes. That's not quite accurate. It means elements that are locally declared within a complex type will not have any namespace URI. It's the namespace that matters, not the prefix.

Thirdly, the whole point of elementFormDefault=unqualified (which is very rarely used, incidentally) is to say that you don't need to put elements in a namespace because they are disambiguated by context. Yes, this allows you to have two different elements with the same name, and with different content models. If you think that's a bad idea, then don't do it. But it's quite viable to distinguish two TITLE elements by virtue of the fact that one has BOOK as a parent and the other has PERSON; some people would say that's often a simpler approach than putting them in different namespaces.

Upvotes: 2

csauvanet
csauvanet

Reputation: 554

To me this is not a valid scenario, XSD definition must never clash or it will make your set of XSD invalid. If 2 entities has the same name and must be used/imported in a common schema, then they must be differentiated by namespace (elementFormDefault qualified, targetnamespace - and default namespace - present).

If you are using a good XML Schema validator, it should raise an error, or at least a warning. In case it is 'not invalid', this is quite dangerous as a parser or validator would randomly chose one of the definition.

I will do an update if I can find the few lines in w3.org that assert this :-)

Upvotes: 2

Related Questions