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: V3 Proposal: Namespace Manager Function
I support this proposal, Joe. The proposed function could have value in the core components area, also, especially in providing "same-as except for" building of new schema.
 
Sally
-----Original Message-----
From: CHIUSANO, Joseph [mailto:JCHIUSANO@lmi.org]
Sent: Monday, January 28, 2002 3:06 PM
To: regrep@lists.oasis-open.org
Subject: [regrep] V3 Proposal: Namespace Manager Function

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
**************************************************************************




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


Powered by eList eXpress LLC