ebXML Representtion of Metadata

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Representation of Metadata in ebXML

This submission is a proposal by the author, Bob Miller, and has not been
yet undergone review by the ebXML Project Teams.  As such, it has no
official standing.

The ebXML requirement for interoperability among both existing and future
XML implementations imposes a functional requirement for the machine
recognition of semantic and syntactic properties of XML elements which
comprise compliant ebXML documents.  Such properties are commonly referred
to as metadata.  

XML 1.0 provides a basic capability for representing metadata via the use of
attributes associated with XML elements.  The XML Schema work in progress in
W3C provides a somewhat more sophisticated mechanism.  This work has not yet
achieved the level of a W3C Recommendation.  The Resource Description
Framework (RDF) Model and Syntax Specification, which has reached the W3C
Candidate Recommendation level, is part of the W3C Metadata Activity, and it
provides a broad capability for representing data objects.  It supports the
concepts of object classes, superclasses, and subclasses, of common
properties (including constraints) of such objects, and of extension to user
defined properties of such objects.   

Metadata defined in an RDF can be used to automatically generate an XML DTD,
Schema, or other XML syntax useful in validating compliance of an XML
document to defined properties of the elements comprising the document.
Metadata defined in an RDF is itself representable in XML, and a concrete
syntax for such representation is defined in the RDF specification.

Upon careful review of the XML DTD, XML Schema, and RDF specifications, I
conclude that the RDF specification is most capable of representing the
metadata properties of Core Components and other business data objects
defined by the ebXML specifications.    

To support this recommendation, I propose the following condition be
satisfied for any document which claims ebXML compliance:

				Compliance to ebXML specifications requires
that each XML element that appears in an XML document asserting ebXML
compliance shall: 
*	provide a pointer, either as an explicit attribute definition in the
XML element usage instance or by prior reference to a default attribute
definition for the XML element to an RDF/XML representation of metadata
associated with the XML element
*	define in each referenced RDF at least such minimal properties as
may be specified as required for compliance by the ebXML specifications.

The ebXML specification shall define a well known attribute name within a
namespace defined by the ebXML specification, to contain the pointer to the
RDF metadata.  The ebXML specifcation shall also specify the names of
properties, in such namespaces as appropriate, which are to be used to
define specific metadata properties required or optional in the ebXML
specification.  Additional properties not defined by the ebXML specification
may be provided in namespaces not defined by ebXML.  Such additional
properties shall be outside the scope of the ebXML specification 

I suggest that the attribute name chosen to represent this pointer be named 
	'RDF'
prefaced of course by the namespace qualifier that identifies the ebXML
namespace.  

A key feature of this design is the storage of metadata associated with
business objects and core components in a common format approved by the W3C
as a Candidate Recommendation, accessible as needed via a pointer mechanism
associated with the individual XML elements which comprise a document.  For
an existing XML document defined without knowledge of ebXML requirements,
conformance to ebXML can be achieved through simple enrichment of the DTD
(or Schema) used to define the document.

Also, minimal overhead is imposed on the processing of an ebXML document
when there is no business need to dynamically traverse the associated
metadata. In the normal case of repetitive use of a common business
document, traversal of the metadata would likely be a one-time activity used
to establish mappings between the business application and the document
content.  Similarly, construction of a Schema to provide partial validation
of document content would be a one-time activity.  The choice to apply
Schema validation to incoming or outgoing documents during testing and
during live production is left to user discretion.
 

In my opinion, the ebXML Core Components should assume responsibility for
specifying the required and optional ebXML RDF properties for use both in
the definition of Core Components and in the definition of other data
objects required to define an ebXML compliant document.  

The RDF specification is syntax neutral, and so meets the requirement that
Core Components work output should be syntax neutral.  Since a concrete
representation of RDF in XML also exists, there appears to be no need for
the Registry and Repository team to address the representation of the output
of the Core Component team in XML syntax.  There may remain a need for the
Registry and Repository team to cooperate with the Business Process and Core
Component teams to define the RDF representation of the output of the
Business Process team. 


Cheers,
             Bob