[
Lists Home |
Date Index |
Thread Index
]
From: "Bill de hÓra" <bill@dehora.net>
>
> Seairth Jacobs wrote:
> >
> > 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.
No, in this case, I am saying the primary vocabulary *never* uses
namespaces, regardless of whether there are secondary vocabularies or not.
This would mean that no change in code would be required to handle the
primary vocabulary. I agree that the "sometimes" approach is not good. But
I do not see a need to namespace the primary vocabulary under any
circumstances. This would also mean that an processor that was not
namespace-aware could still handle the primary vocabulary elements
successfully. At the same time, a namespace-aware processor wouldn't have
any problem handling it either.
> > Secondary
> > vocabularies are always namespaced.
>
> See permathreads elsewhere.
Yeah... I know. I'm sure there are ways to normalize multiple vocabularies
so that no namespacing is required at all. But for the general masses, it
seems to me that always namespacing the secondary vocabularies would be a
good rule-of-thumb. At the same time, it also allows easy visual separation
of the primary vocabulary (no namespace) from secondary vocabularies
(namespaced).
> > 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?
Suppose you have a vocabulary A that expects to be used with other
vocabularies. Vocabulary A has an attribute that can be placed in the
elements of secondary vocabulary elements (like the "mustUnderstand"
attribute in SOAP, as I understand it). In this case, even though the
attribute is of the same vocabulary it is being used in a secondary manner
(or tertiary, if you like). As a result, the attribute itself is
namespaced. So you end up with something like:
<A xmlns:ns1="Vocab1" xmlns:ns2="Vocab2" >
<B>
<ns2:X ns1:mustUnderstand="1" />
</B>
</A>
<A> and <B> are in the primary vocabulary (Vocab1). <X> is in the secondary
vocabulary. "mustUnderstand" is an attribute defined in Vocab1, but it is
not being used as in the primary fashion and is therefore namespaced (since
it wouldn't be used in any elements except secondary elements).
> 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.
At any rate, I don't think these limitations are a bad thing, necessarily.
To me, it would provide simple, consistent rules about when to use
namespaces and when not to use namespaces. Obviously, those rules are not
set in stone. There's always going to be a need to use namespaces in other
ways. But this seemed like a good rule-of-thumb to follow...
---
Seairth Jacobs
seairth@seairth.com
|
