Lists Home |
Date Index |
I originally thought the latter, but I've since come around to the
Great - hang on a little while (hopefully not more than 1 year), and
you'll get this as part of the OASIS/ebXML Registry specification. I've
been pressing on for a Namespace Management function in the
specification for about a year and a half now, and our (imminent)
version 3.0 specification contains some features that lay the groundwork
for this to happen in version 4.0 (or in-between versions as a Technical
Note). Some use cases that I'm pressing ahead on are:
- Registration/maintenance/discovery of a namespace identifier;
- Association of a namespace identifier with all registered XML schemas
in which that namespace identifier represents the target namespace;
- Changing a namespace identifier in the registry, and having it
propagate (with user permission) to all pertinent registered XML schemas
and XML documents;
- Robust querying such as "give me a list of all XML
artifacts/schemas/documents that are associated with namespace XYZ;
- URN *or* URL representation of namespace identifiers (i.e. as a schema
author chooses)- both tie back to the same namespace in the registry;
So I got to thinking perhaps what's really needed is some sort of hybrid
authority structure. At the top, centralized, is an authority of
authorities. It's basically a registry of very short string namespace
authority identifiers (2-4 name characters) that are registered with a
well-known trusted authority.
What you're referencing here is what I term a "hierarchical registry
model" in which "child" registries live under "parent" registries. So
the next question would be visibility - I've written (in various
documents) that a "child" registry may have visibility into one or more
"functional namespaces" (like partitions, not XML namespaces) of a
"parent" registry. IOW, the child registry would "subscribe" to one or
more namespaces. Ultimately, these functional namespaces *could* be
manifested as XML namespaces in XML schemas/documents. The parent
registry would give the child registry "permission" to have access
(read/write, etc.) to one or more namespaces. Additionally, each parent
registry could give its child registries visibility into one or more
namespaces of *its* parent registries, etc. - the possibilities here are
There are also a plethora of other potential models such as centralized
registry, peer-to-peer, etc.
In terms of authorities, in ISO/IEC 11179 (standard for metadata
registries) terms it is called a "Registry Authority" (RA). If you
haven't yet seen this standard, I would highly recommend you check it
where Creo is the authority (identified by 'creo') for the namespace ID
I would *strongly* advise not mixing these - let the registry tell you
who the authority is. If the authority changed, all namespace prefixes
would have to change as well (but I realize that you're not recommending
registering namespace prefixes). Also, I think you meant to say "for the
namespace ID that is represented in the XML document by prefix XYZ". It
appears that there's an unintentional mixing here of namespace prefix/ID
How the various registered namespace authorities manage their namespace
ID's is up to them.
Actually, with a clearly defined governance structure, it would be up to
the governance authority that is above the namespace authories.
There would be one unvouched for magic global namespace authority
identifier, such as 'glob' than anyone can use who isn't registered as a
Sounds like a hierarchical namespace ID stucture, such as a URN affords
you. So there would be a "base" URN (or URL), and some/all of the
namespace IDs would extend from this URN/URL.
Booz | Allen | Hamilton
Jeff Lowery wrote:
> > Perhaps it may help if we scope this a bit else spin our wheels for
> > eternity. Are we speaking here of a registry model/standard that can be
> > implemented and used by public and private authorities alike, or a
> > single, centralized public registry that is under a single authority?
> I originally thought the latter, but I've since come around to the former.
> Let me explain:
> My original thought was a centralized, simple repository of unique,
> short-string namespace ID's (which can be used a prefixes to local names),
> managed by some single authority. I hadn't thought thru the political
> issues, because frankly I wasn't sure the idea had technical merit. So far,
> no one's convince me of any fatal technical flaw (it is a pretty simple, if
> brutish, idea after all).
> However, as Norm pointed out, when you need an [ID], you want it now. You
> don't want to have to go through hoops.
> So I got to thinking perhaps what's really needed is some sort of hybrid
> authority structure. At the top, centralized, is an authority of
> authorities. It's basically a registry of very short string namespace
> authority identifiers (2-4 name characters) that are registered with a
> well-known trusted authority. Once you're a registered namespace authority
> with this authority (sorry, I hope I'm not confusing you), then your free to
> create and manage your own namespace IDs, in whatever manner you see fit.
> What you wind up with are ID prefixes something like:
> <creo_ppsg:ProjectSpec foo="quux">
> where Creo is the authority (identified by 'creo') for the namespace ID
> 'ppsg'. The '_' is a separator (which I think is an allowed Name character,
> though I wouldn't swear to it). Likewise, Adobe (adbe) is the namespace
> authority for the ID 'PDF'.
> How the various registered namespace authorities manage their namespace ID's
> is up to them. Nobody else, however, can use 'creo_' or 'adbe_' at the
> beginning of their namespace IDs.
> There would be one unvouched for magic global namespace authority
> identifier, such as 'glob' than anyone can use who isn't registered as a
> namespace authority:
> Anyway, that's about as far as I've given thought to it. I think that's
> about as far as I want to write about it, anyway. ;-} I got to get back to
> making this darn SOAP client work now.
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
fn:Joseph M. Chiusano