Re: [regrep] V3 Proposal: Namespace Manager Function

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

Joe,

Your description of a possible implementation added clarity to the
picture.

The difference between client side Vs. registry core functionality seems
to be that implementing it as core registry feature allows the registry
to automatically harvest namespaces and their constituents and build up
a rich database of such information. Doing it on the client side means
that since not all schemas will be submitted via the client, there is no
automatic harvesting of the information. Obviously, it is desirable to
support the automatic harvesting of namespace information and thats
upports implementing this as registry functionality.

Now that I understand the need, I observe that the need may also be met
by another more general purpose feature called "Content-based queries".
The similarity I see is taht content-based queries at least how it has
been envisioned on a couple of occasions in the past does automatic
indexing of submitted schema based on a pluggable ContentIndexer (which
is a web service registered with the registry). Well what if that
pluggable ContentIndexer is the NameSpace indexer? If we did things this
way, then we piggy-back on content-based queries and then spec a
required normative content indexer for the registry called the
NameSpaceIndexer. Thus your proposal would still require a normative
spec addition but it would be based on the content-based query normative
specification addition. I would reccomend that the task you propose be
done within teh query sub-team who would also work on content-based
queries.

Lets hear from other team members and see what ideas transpire on this
interesting thread.

"CHIUSANO, Joseph" wrote:

>
>
> Farrukh,
>
> Thank you for your feedback.  I was thinking in terms of core registry
> functionality, but would like to here more about what you are
> thinking.  I say core primarily because there would need to be some
> sort of association between the constructs (elements, attributes,
> types) and their namespaces - therefore, it seems like a core-type
> function to me.
>
> I know this is getting into implementation, but my initial thoughts
> were to have some functionality that would parse a schema upon
> registration and extract the namespace declarations from the root
> element (and non-root elements, for local namespace declarations);
> then, given the declared namespace prefix (assuming the namespace in
> this case isn't default namespace), parse the schema for all
> constructs that are preceded by that prefix - then, store the
> namespace (unless it is already known to the registry) and its
> constructs in the registry (and possibly the prefix as well).  Now
> that this information is in the registry, the 4 cases described below
> can be satisfied.
>
> Looking forward to your ideas.
>
> Joe
>
> >
> **************************************************************************
>
> >   Joseph M. Chiusano
> >   Logistics Management Institute
> >   2000 Corporate Ridge
> >   McLean, VA 22102
> >   Email: jchiusano@lmi.org
> >   Tel: 571.633.7722
> >
> **************************************************************************
>
> >
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> Sent: Monday, January 28, 2002 3:51 PM
> To: CHIUSANO, Joseph
> Cc: regrep@lists.oasis-open.org
> Subject: Re: [regrep] V3 Proposal: Namespace Manager Function
>
> 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

--
Regards,
Farrukh