ebXML Registration of FineGrained Artifacts

1
Registration of Fine-Grained XML Artifacts in
ebXML Registry
Joseph M. Chiusano Booz Allen Hamilton
Federal XML Community of Practice (xmlCoP)
Meeting Washington, DC December 17, 2004
2
A Technical Note is underway within the
OASIS/ebXML Registry Technical Committee for the
registration of fine-grained XML artifacts

• Fine-grained XML artifacts are XML constructs
  that are building blocks for XML-based
  transaction definitions in electronic information
  exchanges
• These XML-based transaction definitions are often
  represented as XML schemas based on controlled
  vocabularies
• Such controlled vocabularies often represent the
  information domain for Communities of Interest
  (CoIs)
• We will refer to these XML-based transaction
  definitions as XML-based vocabularies
• Fine-grained XML artifacts include
• Elements
• Attributes
• Data Types
• Namespaces
• Metadata registries provide a means by which
  metadata can be registered, discovered,
  maintained, shared, and evolved
• Such registries can support Communities of
  Interest (CoIs) in governing and evolving
  controlled vocabularies
• Examples of metadata registry standards are ebXML
  Registry and ISO/IEC 11179

3
There has been a growing need for information
exchange partners and Communities of Interest to
maintain XML artifacts at a fine-grained level
within metadata registries, using an open standard

• This enables XML-based vocabularies to be managed
  and to evolve as a building blocks, rather than
  monolithic, high-level artifacts
• Such support will allow discovery and reuse of
  these artifacts in multiple higher-level
  artifacts
• Can gain efficiencies of reuse, as well as
  consistency in representation and usage
• Consider the following example involving an
  OrganizationName element

Registration of the OrganizationName element in
a registry enables its consistent usage in
multiple XML schemas
4
The ebXML Registry standard is a metadata
registry standard that supports the registration,
maintenance and discovery of both XML- and
non-XML artifacts

• The ebXML Registry version 1.0 standards were
  developed during the OASIS/UNCEFACT Electronic
  Business XML (ebXML) initiative and approved in
  May 2001
• ebXML is a modular suite of standards for
  conducting electronic business
• It provides a method for companies to exchange
  business messages, develop trading relationships,
  communicate in common terms, and register and
  define business processes
• An ebXML Registry enables the sharing of
  information between entities through cooperation
  and collaboration, and it increases efficiency in
  XML-related development efforts as well as
  runtime interactions such as dynamic discovery of
  Web Service artifacts (e.g. WSDL documents)
• The OASIS/ebXML Registry Technical Committee
  Technical Committee continues to develop the
  ebXML Registry standards
• The ebXML Registry version 2.0 standards are OASIS
  approved and ISO approved standards (ISO 15000-3
  and ISO 15000-4)
• The ebXML Registry version 3.0 specifications
  will be in the OASIS public review process in
  early 2005

5
A few basic facts about the ebXML Registry
architecture will help us better understand why
this Technical Note is needed

• The ebXML Registry Information Model (ebRIM) is
  an abstract information model that is meant to
  support any type of content
• Some classes within ebRIM are intrinsic to the
  registry, as they need to be natively
  recognized in order for the registry to carry
  out its functions, and for interoperability
  between registries
• Exs Classification Scheme, Organization,
  Service, ExternalLink
• All other registered content is represented by an
  ExtrinsicObject class whose metadata describes
  submitted content whose type is not intrinsically
  known to the registry
• This content must be described by means of
  additional attributes, such asObject Type, MIME
  Type, and other custom attributes (Slots)
• The foundational class in ebRIM is the
  RegistryObject class
• Represents all ebRIM classes whose instances have
  a unique identity
• This includes both intrinsic and extrinsic
  classes
• The RegistryEntry class inherits from the
  RegistryObject class
• It represents higher-level, coarse-grained
  objects that require additional metadata beyond
  that provided by the RegistryObject class
• Examples Expiration Date, Stability

6
A few basic facts about the ebXML Registry
architecture will help us better understand why
this Technical Note is needed (contd)

• Content that is stored in a repository associated
  with a registry is represented by the
  RepositoryItem class
• Examples XML schema, DTD, document
• Each RepositoryItem is associated within an
  ExtrinsicObject instance
• RegistryObject instances are categorized
  according to classification schemes
• Classification schemes may be internal to the
  registry, or external (e.g. NAICS)
• Each RegistryObject instance has an objectType
  attribute
• This covers both intrinsic (e.g.
  ClassificationScheme) and extrinsic (e.g. some
  custom type) classes
• RegistryObjects are classified according to an
  ObjectType classification scheme that is native
  to the registry
• This scheme can be customized for
  ExtrinsicObjects
• RegistryObject instances are related through
  predefined associations
• Exs Object1 replaces Object2, Object1
  extends Object2
• ebXML Registry Version 3.0 introduces a
  Cooperating Registries features that provides
  support for distributed ebXML Registries to
  cooperate with each other

7
The following class diagram represents the ebXML
Registry Information Model (ebRIM)

• The central class is the RegistryObject class

8
Although the generic capabilities of ebXML
Registry have always supported fine grained XML
artifact registration, at present no document
describes how this should be done as a best
practice

• Such artifacts can be registered in an ebXML
  Registry, but their metadata content is
  determined by each individual submitter
• This means that such artifacts can be represented
  as different object types by different
  submitters, which impedes interoperability
• Examples Element, XML Element, Data
  Element
• The thinking behind this need has existed for
  several years within the OASIS/ebXML Registry
  Technical Committee
• July 2001 Proposal to Allow Registration of XML
  Tags (Joseph Chiusano)
• This document proposes enhancements to the ebXML
  registry specifications to allow XML tags to be
  treated as registered objects (see archive for
  rest) http//lists.oasis-open.org/archives/regrep
  /200107/msg00016.html
• January 2002 V3 Proposal Namespace Manager
  Function (Joseph Chiusano)
• A Namespace Manager function would allow a
  registry client to manage XML namespaces.This
  includes the ability to (see archive for rest)
• http//lists.oasis-open.org/archives/regrep/2002
  01/msg00061.html

A Technical Note is now underway that will
satisfy these needs
9
The Fine-Grained XML Artifacts Technical Note
will describe how such artifacts can be managed
as RegistryObjects within ebRIM in a standard
manner, using the existing registry capabilities

• Consider the following query across multiple
  ebXML registries, using ExtrinsicObjects to
  represent XML elements

Find all elements that are of data type
xsdecimal
Differences in ObjectType classifications and
metadata impedes interoperability
10
The Technical Note will lay a foundation for
increased flexibility in management and evolution
of XML-based vocabularies using ebXML Registry

• XML artifacts can be managed and reused at
  fine-grained levels
• This means that such artifacts can be evolved
  separately from the higher-level artifacts in
  which they appear
• They can also be shared across Communities of
  Interest
• Consistency in representation and usage can
  decrease the level of errors in information
  exchanges
• Automatic schema assembly tools can assembly
  schemas from registered fine-grained artifacts
• The existing capabilities of ebXML Registry will
  be automatically leveraged
• Query management
• Custom metadata attributes (Slots)
• Lifecycle management
• Event notification
• Security
• etc.

11
Some preliminary thinking has already been done
regarding the scope of the Technical Note and the
proposed approach

• The following are some high-level categories that
  use cases will cover
• Registration
• Discovery
• Update
• Lifecycle
• Notification
• Examples of Registration use cases are
• Register an XML element
• Registry a namespace identifier
• Examples of Discovery use cases are
• Discover all elements that are in the namespace
  whose identifier is http//www.abc.com
• Discover all XML schemas that contain an element
  whose data type is xsdecimal

12
Some preliminary thinking has already been done
regarding the scope of the Technical Note and the
proposed approach (contd)

• Examples of Update use cases are
• Move all elements that are in the namespace whose
  identifier is http//www.abc.com to the
  namespace whose identifier is http//www.xyz.com
  
• Change all attributes named currency to
  elements
• Examples of Lifecycle use cases are
• Delete all elements that are in the namespace
  whose identifier is http//www.abc.com
• Approve a specific set of elements
• Examples of Notify use cases are
• Notify all users that are subscribed to a given
  schema if the definition of one of its elements
  changes in the registry
• Notify functional namespace managers of any
  updates to fine-grained XML artifacts within
  their namespace

13
Some preliminary thinking has already been done
regarding the scope of the Technical Note and the
proposed approach (contd)

• Fine-grained XML artifacts will be represented as
  ExtrinsicObjects
• No RepositoryItem will be required
• Serialization of XML-formatted data can be done
  according to the XML standard, therefore there is
  no need to store the representation of a
  fine-grained XML artifact
• Namespaces will be represented by namespace
  identifiers
• Can map to functional namespaces
• Associations will be used to associate elements
  with their corresponding data types, and complex
  data types with their comprising elements
• They can also associate XML schemas with the
  RepositoryItems for the elements that comprise
  them
• The OASIS/ebXML Registry version 3.0 Content
  Management Services feature can be used to parse
  registered schemas and register all fine-grained
  XML artifacts that comprise them
• Will align with UN/CEFACT Core Components and the
  OASIS/ebXML Registry Semantic Content Management
  Subcommittee work in future

14
A multi-faceted approach will be used to
determine the metadata that should be represented
for each fine-grained XML artifact in the registry

• The XML Information Set (XML Infoset) standard
  will be referenced for potential custom
  attributes for fine-grained XML artifact
  RepositoryItems
• Some information items are already covered in the
  current thinking (e.g. element information items,
  attribute information items)
• Some may not be of much value to capture (e.g.
  character information items, notation information
  items)
• The W3C Schema standard will be referenced for
  potential features that should be accommodated as
  associations, as well as other potential
  RepositoryItems
• Examples Model groups, substitution groups,
  patterns
• Need to ensure a balance between those
  representations that should be handled by schema
  assembly tools, and those that should be captured
  in the registry
• Examples minOccurs/maxOccurs, fixed values,
  global vs. local representation

15
Next Steps

• Elicit feedback from federal XML community on
  those use cases of most interest in the federal
  space
• Further refine scope
• Drill down deeper into requirements
• Present updates at future xmlCoP meetings
• Completion anticipated mid-2005

16
Questions?
17
Contact Information

• Joseph M. Chiusano
• Booz Allen Hamilton
• McLean, VA
• [phone]
• chiusano_joseph_at_bah.com