Re: [regrep] [ebXML Registry and Fine-Grained Registration][Fwd: .govXML Registry Services]

[Duane Nickull <dnickull@adobe.com>]

I just submitted a registry briefing on using CCTS within a registry for 
eGov.

Duane

Carl Mattocks wrote:

>which is pretty much the topic of ...
>the XMXL 2004 presentation title I just submitted 'Guidelines for
>e-Government Service Schema Component Management using an ebXML Registry /
>Repository'
>
>The objective of this presentation is to provide guidelines on how the
>standards being developed by the OASIS ebXML Registry and Context Assembly
>Mechanism Technical Committees can help meet the needs of e-Government
>Service providers. The primary focus of the guidelines is to support a
>usage scenario that includes  ¡V
>h Registration and storage of  e-Government Service Metadata (EGSM)
>artifacts
>h Registration and storage of  Schema Components used in many distinct
>Schemas
>h Storage of the knowledge embedded in a registered Data Dictionary
>h Use of Data Dictionary items when managing schema components
>h Use of Registry / Repository ¡¥Context Declaration¡¦ when managing
>schemas employing UN/CEFACT Core Components
>h Use of CAM (Context Assembly Mechanism) for binding structural,
>contextual and referential information to schema components
>h Classification of EGSM, Data Dictionary Items, Schema Components,
>Context Declarations and Context Assembly Mechanism to facilitate
>discovery and deployment
>In particular, the scope of this guideline includes:
>h Many objects are defined by data type (Anonymous data types are not used)
>h Namespaces are defined for certain types of content
>h Messages are defined as XML Schemas
>
>Further that Schema component life cycle management employs the W3C XML
>Schema recommendation that includes:
>h registering proposed schema components as drafts;
>h reviewing proposed schema components;
>h registering approved schema components;
>h assembling complete schemas from components; and
>h managing the lifecycle of the components and schemas.
>
>In terms of publishing content the ebXML Registry / Repository
>specification supports:
>h publishing to a central registry / repository; or
>h publishing to a federation of many individually many registry /
>repository facilities.
>
>The audience will be shown the characteristics of a classification
>structure supporting the discovery and deployment of schema components in
>a target namespace relating to the project for which the schema is being
>developed. Wherein, the stages of discovery & deployment activities
>include:
>h search for suitable components
>h develop new components
>h develop the structure of the new schema centric documents/messages
>h register the new schema components and documents/messages
>h notify users of new versions of components that they are using
>h identify users of obsolescent components
>h remove obsolete components
>
>Understanding that the UN/CEFACT Core Components Technical Specification
>version 2.0 contains a logical data model for a core component - the
>presentation participants will learn that the terminology used for the
>Core Components working group¡¦s BIE is synonymous a Data Dictionary
>Element. The key difference being that UN/CEFACT CCWG Core Component is
>envisioned as a global set of business collaborations vs. the typical
>local Data Dictionary has been scoped solely for a particular domain.
>
>Attendees will also learn how the Context Assembly Mechanism employs
>templates to bind structural, contextual and referential information to
>schema components. Wherein using CAM <context condition=¡¨XPath
>expression¡¨/> allows for dynamic assignments of context to a Schema
>Component instance , such as, assigning additional properties to message
>when it is routed via a ¡¥Reliable Messaging System ¡¥.
>
>
>
><quote who="Chiusano Joseph">
>  
>
>>On the topic of "fine-grained" registration (elements/attributes/data
>>types/namespace identifiers) which I note that we are moving closer to
>>with our SCM efforts:
>>
>>The e-mail below came to me (and other individuals) from a US federal
>>government person whose primary job involves XML (I have removed their
>>identity to respect their privacy). The points that this individual
>>makes regarding data elements and "the registry" (that is, a federal
>>government registry or series of registries) echo the urgency of
>>accomodating this functionality in our architecture.
>>
>>Thanks,
>>Joe
>>
>>-------- Original Message --------
>>Subject: .gov XML Registry Services
>>Date: Fri, 7 May 2004 09:07:46 -0400
>>From: REMOVED
>>To: REMOVED
>>
>>[snip]
>>
>>Other points I'd like to make include:
>>
>>1) The registry should become the actionable embodiment of the FEA DRM.
>>That is: a) the elements and controlled vocabulary specified in the DRM
>>should be represented in XML, to facilitate referencing and reuse; and
>>b)
>>those representations should be made available in the XML registry for
>>ease
>>of discovery, access, and use.
>>
>>It is now far harder than it should be for folks to discover and reuse
>>data
>>elements, not to mention actual instances of data.  So they are often
>>left
>>with no practical choice but to reinvent the data elements they need to
>>conduct business they are required to carry out.  The XML registry will
>>help to overcome that problem.  It is a basic, enabling component of the
>>worldwide information infrastructure.  It is also essential to the
>>efficient and effective implementation of *all* of the eGov initiatives,
>>particularly those that involve the collection of highly structured
>>(forms-based) data.
>>
>>[snip]
>>
>>To unsubscribe from this mailing list (and be removed from the roster of
>>the OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>>
>>
>>    
>>
>
>
>  
>

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com