1 / 17

Federal XML Community of Practice (xmlCoP) Meeting Washington, DC December 17, 2004

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.

alfonso-roberts
Download Presentation

Federal XML Community of Practice (xmlCoP) Meeting Washington, DC December 17, 2004

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. <xsd:element name=“ReportDetails"> <xsd:complexType> <xsd:sequence> <xsd:element ref=“rpt:ReportID" <xsd:element ref="core:OrganizationName"/> .... </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="SubmitterDetails"> <xsd:complexType> <xsd:sequence> <xsd:element ref="core:OrganizationName"/> <xsd:element ref="core:Address"/> .... </xsd:sequence> </xsd:complexType> </xsd:element> “OrganizationName” element, Core namespace Metadata Registry 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 CommitteeTechnical 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 • 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

  6. 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

  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/200201/msg00061.html A Technical Note is now underway that will satisfy these needs

  9. ExtrinsicObject ClassificationScheme: • ExtrinsicObject • XML Schema • User Manual • Fine-Grained Artifacts • XML Elements • XML Attribute • etc. • ExtrinsicObject ClassificationScheme: • ExtrinsicObject • XML Schema • Image • Element • Attribute • etc. Fine-grained artifacts Fine-grained artifacts ebXML Registry #2 ebXML Registry #1 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” 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 “xs:decimal”

  12. 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

  13. 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

  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 • (703) 902-6923 • chiusano_joseph@bah.com

More Related