Lists Home |
Date Index |
Seairth Jacobs wrote:
> From: "Bill de hÓra" <email@example.com>
>>If primary and secondary are roles a vocabulary plays determined by
>>whether it's the root element, then you're talking about
>>vocabularies being sometimes being in a namespace, and sometimes
>>not, depending on whether the the root element in the vocabulary
>>is the root element in a document. That's arguably worse than a rule
>>saying primary vocabs are fixed to the root and can't be embedded.
>>Essentially you're mandating element names in a vocabulary must
>>change if the vocabulary is the root element in a document. I've
>>seen people do things like that, it's problematic at best.
> You've lost me here. All I was suggesting is that, for a given document,
> the primary vocabulary (the one that's associated to the doctype) should
> never be namespaced. I see no point in namespacing it.
Normally, I see no point in namespacing any vocabulary. But I really
see no point in not namespacing whatever's at the root, and
namespacing it when it is not, or even whether that's workable. What
is it you think you gain by doing this?
> Regardless of
> whether other vocabularies are mixed into the same document, no namespace is
> needed for the primary vocabulary (while all other vocabularies must be
> namespaced). If that same vocabulary is used in another document not as the
> primary vocabulary, then it would be namespaced. I certainly don't see a
> need to change element names (any more than the colonified name hack does).
> Why would this approach be problematic?
Where does the namespace for that vocabulary come from?
> What am I missing?
That there's no need to give a vocabulary two sets of names.
Especially for an optimization that only makes sense within a single
trust boundary ('local' as Sean and Simon put it).
Bill de hÓra