Transcript ebXML Registration of Fine

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
0
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
1
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 higherlevel artifacts
– Can gain efficiencies of reuse, as well as consistency in representation and usage
 Consider the following example involving an “OrganizationName” element:
<xsd:element name=“ReportDetails">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref=“rpt:ReportID"
<xsd:element ref="core:OrganizationName"/>
....
</xsd:sequence>
</xsd:complexType>
</xsd:element>
“OrganizationName”
element, Core namespace
Metadata
Registry
<xsd:element name="SubmitterDetails">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="core:OrganizationName"/>
<xsd:element ref="core:Address"/>
....
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Registration of the
“OrganizationName” element
in a registry enables its
consistent usage in multiple
XML schemas
2
The ebXML Registry standard is a metadata registry standard that
supports the registration, maintenance and discovery of both XMLand 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
3
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
 Ex’s: 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
as:Object 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
4
A few basic facts about the ebXML Registry architecture will help us
better understand why this Technical Note is needed (cont’d)
 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
– Ex’s: 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
5
The following class diagram represents the ebXML Registry
Information Model (ebRIM)
 The central class is the RegistryObject class
6
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/200201/msg00061.html
A Technical Note is now underway that will satisfy these needs
7
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 “xs:decimal”
ExtrinsicObject
ClassificationScheme:
• ExtrinsicObject
– XML Schema
– Image
– Element
– Attribute
– etc.
Fine-grained
artifacts
ebXML
Registry #1
Differences in ObjectType
classifications and metadata
impedes interoperability
ExtrinsicObject
ClassificationScheme:
• ExtrinsicObject
– XML Schema
– User Manual
– Fine-Grained Artifacts
 XML Elements
 XML Attribute
 etc.
Fine-grained
artifacts
ebXML
Registry #2
8
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.
9
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
“xs:decimal”
10
Some preliminary thinking has already been done regarding the scope
of the Technical Note and the proposed approach (cont’d)
 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
11
Some preliminary thinking has already been done regarding the scope
of the Technical Note and the proposed approach (cont’d)
 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
12
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
13
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
14
Questions?
15
Contact Information
Joseph M. Chiusano
Booz Allen Hamilton
McLean, VA
(703) 902-6923
[email protected]
16