OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [regrep] V3 Proposal: Namespace Manager Function


Title: RE: [regrep] V3 Proposal: Namespace Manager Function

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC