Lists Home |
Date Index |
Seairth Jacobs wrote:
> The whole xmlns thread has left me more confused about what should and
> should not be done with namespaces... so, can someone answer these
> 1) Suppose you have a vocabulary that states that only <B> may be within
> <A>. Now suppose you have another vocabulary with element <C>. If one were
> to do <ns1:A><ns1:B/><ns2:C/></ns1:A>, would the document still be valid
> according to the first vocabulary?
If I understand you, no. <A> and <ns1:A> are different things. You
probably could write RNG that would validate both but it would be a
> 2) Given the various levels of support for xml namespaces in tools, what
> would be the pros/cons of the following practice:
> The document's primary vocabulary is never namespaced.
No reason for this that I can think of. Once you're using
namespaces, you don't gain much by only using them sometimes.
> vocabularies are always namespaced.
See permathreads elsewhere.
> Default namespacing is never used.
Yes. Default namespaces don't play nice with non-namespaced XML.
This allows you to add non-namespaced elements with the comfort of
knowing you haven't accidently adding them into a namespace. A
default ns is for situations where you know you don't want to mix
But it is an extra constraint, and you'd need to coordinate all
processors to obey it. It only takes once process to start acting
the maggot with a default namespaces to poison the the well.
> the primary vocabulary will also act in a secondary fashion (e.g.
> "mustUnderstand" in SOAP), then it will be namespaced.
Lost me. Are you talking about recursive structures?
But the key thing. Once you use namespaces you should use them as
given, and be prepared to absorb the overhead involved. Adding
processing rules and constraints over and above the Namespaces spec
hasn't been a winning approach in my experience - the singe
exception being the elimination of the default namespace.
Bill de hÓra