Re: [regrep] V3 Proposal: Namespace Manager Function

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Joe,

The functionailty you describe sounds very useful. At first blush it
seems to be a nifty use of our existing V2 registry specs rather than
V3]
functionality. In other words it seems to be a client side application
rather than specific core registry functionality. A similar example
would be to use
the registry to keep run a site like Napster (store mebership info)
without making changes to core registry functionality.

To summarize my initial thinking, could we not do 1-4 via a stylized use
of our current specs? Is rthis neat functionality app functionality or
registry functionality?

"CHIUSANO, Joseph" wrote:

>
>
> Hi All,
>
> At our 1/24/02 call, there was a request to provide more details on
> those features that we had proposed for V3.  Therefore, I'd like to
> provide some more specifics on my Namespace Manager function proposal:
>
> A Namespace Manager function would allow a registry client to manage
> XML namespaces.  This includes the ability to:
>
>         (1) Associate constructs (elements, attributes, types) with a
> registered namespace
>
>         (2) Query on all constructs in a given namespace
>
>         (3) Perform a comparison between 2 or more namespaces
>
>         (4) Perform life-cycle-type functions on a namespace
> (registration, deprecation, etc.)
>
> Just this morning, I attended a meeting with a government client who
> clearly demonstrated that there was a need for this type of
> functionality in their environment - hence the proposal.
>
> More on #1:  This would allow constructs used in XML Schemas or XML
> documents to be associated with their namespace within the registry.
> This functionality is necessary for the remaining 3 items that are
> listed.
>
> More on #2:  Suppose a corporation's headquarters had a corporate-wide
> namespace; a branch operation may wish to declare an element as
> existing in their "local" namespace (through the namespace
> functionality inherent with XML Schema), but do not want to do so if
> the corporate-wide namespace already contains the element.  This query
> functionality would allow the branch operation to make this
> determination.
>
> More on #3:  Keeping with the same general scenario, this
> functionality would allow a branch operation to report on (a) all
> constructs that were in their "local" namespace but not in the
> corporate-wide namespace, or (b) all constructs that were in common
> between the 2 namespaces (i.e. perhaps unnecessary duplication), etc.
>
> More on #4:  This would allow a registry user to enforce that any
> namespaces referenced in registered XML Schemas or XML documents must
> reference registered namespaces (if not, take some user-defined action
> such as error notification or automatic registration of a namespace).
> It would also allow a namespace to be retired.
>
> Comments/questions are welcome and appreciated.
>
> Regards,
> Joe
>
>
> *************************************************************************
>
>   Joseph M. Chiusano
>   Logistics Management Institute
>   2000 Corporate Ridge
>   McLean, VA 22102
>   Email: jchiusano@lmi.org
>   Tel: 571.633.7722
>
> *************************************************************************
>
>

--
Regards,
Farrukh