[
Lists Home |
Date Index |
Thread Index
]
That puts namespace strings into a class of property similar
to trademarks. It's not a bad idea where the registries
are not centrally managed, but distributed and coordinated.
Since central management systems usually get in the way of
distributed authority, it is a good idea to figure out how
to keep registrations local but coordinatible. One also should
set the software up to handle temporary namespace assignments
used until the final article is provided. It is the sort of
thing we have to do with any identifier in a non-central database
which is then merged to the master database, and when certain
processes must happen prior to a master identifier being
assigned. (In the example I am thinking about, it relates
to incident and case identifiers.)
The politics for some namespace identifiers are easy; others
are hard. That is one part a technical problem, and one
part the social assignment problem (who's zoomin' who).
I think centralized registration for all identifiers is a
non-starter as a result.
len
From: Jeff Lowery [mailto:Jeff.Lowery@creo.com]
> 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">
<adbe_PDF:dict>
...
</adbe_PDF:dict>
...
</creo_ppsg:ProjectSpec>
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:
<glob_myns:foo/>
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.
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
