Representation classes

["Martin Bryan" <mtbryan@sgml.u-net.com>]

Hisanao

I said
> >The question arises as whether Representation Classes are just instances 
> >of a Data Format or whether they are more fundamental than this. Please 
> >try out the new Data Format form and see if they are missing something 
> >that relates t o the ISO 11179 concept of Representation Classes.

You said 
> -> Disagree.  The representation classes are atomic level of business 
> classes conveying the information of the concept of the value domain and 
> the data type.
> The representation objects shall be expressed in several kinds of the 
> primitive classes("decimal", "string", "boolean",etc) defined accordance 
> with relevant syntax, such as COBOL, JAVA, XML. Since the core components 
> for ebXML should be defined in syntactically neutral, we don't need to 
> develop the set of primitive classes.

Whilst I agree that we should be a syntactically neutral as possible we do have to define the ebXML Data Formats and Code Sets in a way that can be transported across environments - therefore they have to be based on well-known and commonly supported primitive classes such as decimal, string, boolean, etc. In addition it will serve no purpose defining a class that cannot be supported by XML Schemas as the whole purpose of the ebXML initiative is to be able to express electronic business concepts in XML (not COBOL, Java or any other programming language).

What I tried to do in my list was look for gaps in the set of primitives that are widely supported. Most of the Representation Classes you have listed map simply to widely accepted primitives, and can be expressed easily as XML Schema simpleTypes that can be used as the basis of other types, e.g.:

Amount  == <xsd:simpleType name="Amount" base="xsd:decimal"/>
Code == <xsd:simpleType name="Code" base="xsd:string"/>
Description == <xsd:simpleType name="Description" base="xsd:string"/>
Identifier == <xsd:simpleType name="Identifier" base="xsd:string"/>
Name == <xsd:simpleType name="Name" base="xsd:string"/>
Number == <xsd:simpleType name="Number" base="xsd:integer"/>
Percent == <xsd:simpleType name="Percent" base="xsd:decimal"/>
Quantiy == <xsd:simpleType name="Quantity" base="xsd:integer"/>
Date == <xsd:simpleType name="Date" base="xsd:timeInstance"/>
Indicator == <xsd:simpleType name="Indicator" base="xsd:boolean"/>
Measure == <xsd:simpleType name="Measure" base="xsd:decimal"/>
(NB For Measure w may need a more complex type consisting of Decimal + enumeration list of measurement units, as shown in my other message.)

These are all examples of a basic Data Format definition with a predefined name - which corresponds to your Representation Class name. Some of them may need refinement/discussion (e.g. should the base class for Number be decimal or float rather than integer, should Quantity be defined as a decimal, should there be multiple forms of Date, such as DateTime, DateOnly, TimeOnly, etc): I leave this to a later discussion.

Some of the proposed Representation Classes, however, are not in the same class as the above as they do not have simple mappings to primitive classes but are inherently complex.

Age == <xsd:simpleType name="" base="timePeriod or duration
What is an age: is it a simple time period (e.g. P35Y3M), whose value is only true on a specified date, or is it better to represent it as a Date of Birth/Production so that applications can calculate age from subtracting the entered date from the current date? One of the things we have been discussing in the UK is the relationship of this Representation Class to things like Sell By dates and Shelf Life. Whilst you can use Periods to express these in "general" terms, once you get to an instance you need either a specific "End of Permitted Use Date" or a Date of Production that the period can be related to. Finding a single generic definition for this that will work across representations is going to be non-trivial. Can you please provide me with an "rigorous" definition for this Representation Class.

Rate -> Not supported directly in XML Schema - its simply a pair of quantities
Rates are by definition based on a pair of measurements. They are an example of the problem I mentioned with Units of Measurement - they require you to manipulate both the units and the value separately to create a new "combined value". The question this raises is whether a rate should be recorded as the result of processing these units or should it simply be expressed as two measurements that need processing on receipt? For example, is it better to send:
 <Rate units="kg/m^2">12.5</Rate>
or
<Rate>
  <Measurement units="kg">100</Measurement>
  <Measurement units="m^2">8</Measurement>
</Rate>

I am far from convinced that Rate or Age are valid Representation Classes. I am also far from convinced that there is any basic difference, other than name and the presence of a formal definition, between any Representation Class and any other Data Format that might be defined for other applcations of ebXML.

Martin Bryan



=======================================================================
= This is ebxml-core, the general mailing list for the ebXML          =
= Core Components project team. The owner of this list is             =
= owner-ebxml-core@oasis-open.org                                     =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-core                                         =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-core myname@company.com                      =
=======================================================================