OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: FW: ebXML Entity Classes - Resend


I've heard from two individuals that my attachment got mangled.  As it was a
very short attachment, I've converted it to inline text (losing some
editting structure in the process - sigh):

> Some thoughts on ebXML Classes
> 
> Submitted by Bob Miller
> Introduction
> 
> The work of the ebXML Core Components Team establishes a set of  reusable
> semantic entities, and establishes that these entities may exhibit
> parent/child relationships.  Generally, documents which define such
> parent/child relationships do so from a single base class.  This permits
> properties associated with various entities to be elevated to the hishest
> common class to which those properties apply.  
> 
> This submission proposes a base class for all ebXML entities, and two
> direct subclasses, one for aggregate ebXML entities and one for primitive
> ebXML entities.  It suggests that an additional layer of ebXML classes be
> defined to support properties specific to each of the defined ebXML types
> (e.g., type Amount).
> ebXML Semantic Entity Class
> All ebXML entities should derive from a single base ebXML class.  In this
> paper, I identify this class as:
> 
> 	ebXMLSemanticEntityClass
> 
> Properties of this object include:
> 
> OwnerURI
> The URI identifying the owner of the object being defined.  For the
> ebXMLSemanticEntityClass, the owner is TBD.
> 
> OwnerID
> A unique ID in the namespace of the OwnerURI.  For the
> ebXMLSemanticEntityClass, the owner ID is:
> [TBD]
> 	
> EntityName
> A (language-specific) semantic name for the entity.  
> 
> Description
> A (language-specific) prose description of the semantic entity used to
> specify semantic intent and usage of a defined entity.  May be a URI.
> 
> SubClassOf
> The class of which this object is a subclass. For the Base
> ebXMLSemanticEntityClass, the subclass is NULL.
> 
> 
> ebXML Entity Classes
> There are exactly two ebXML Entity Classes derived directly from the Base
> ebXML Class.  These are:
> 
> EbXMLAggregateEntityClass
> 
> The basic ebXML container class, used to contain collections of other
> ebXML entities
> 
> SubclassOf:		ebXMLSemanticEntityClass
> 
> Properties of this object include:
> 
> 
> {properties used to convey content structure for the object - TBD.  At a
> minimum, some ability to express relationships among members of the
> aggregate is needed.)
> 
> 
> EbXMLBasicEntityClass
> 
> 
> The primitive ebXML data entity, used to contain collections of other
> ebXML objects 
> All primitive ebXML data representation types derive from this object
> 
> SubclassOf:		ebXMLSemanticEntityClass
> 
> 
> Properties of this object include:
> MaxLen
> The maximum number of bytes this object is allowed to represent
> 
> MinLen
> 		The minimum number of bytes this object is allowed to
> represent
> 
> 
> EbXMLType
> An ebXML data type selected from an enumeration of defined ebXML data
> types Examples of ebXML data types include 'Amount' and 'Quantity'.  Each
> ebXML data type may be further represented as an ebXML class as a subclass
> of ebXMLBasicEntityClass.
> 
> NOTE: It may be appropriate to add other type properties here, such as the
> types used to express entity values in specific syntax renditions, such as
> XML, X12 and UN/CEFACT.
> 
Personal Comments  

From a UML perspective, I believe the ebXML SemanticEntityClass and
ebXMLBasicEntityClass would be called abstract classes, as they would not be
used directly in entity instantiations.  The ebXMLAggregateEntityClass and
the classes derived from ebXMLBasicEntityClass which are used to represent
defined ebXML types would be concrete classes. 

I pulled this from a prior work I did, and have not attempted to match
nomenclature for the class properties with nomenclature in the ebXML CC
documents.  Also, there may be properties defined in the ebXML CC work that
would be appropriately elevated to the classes I've defined (E.g., the root
class should include the GUID.)

The intent of this submission is to foster discussion whether the ebXML CC
documents should define additional classes to provide a hierarchical class
tree emanting from a root class. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC