RE: Representation Types Alternatives

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

I favor Rawlins 1) Formally define representaiton types
                b) Define a set of types rather than adopt one.

The types defined in the BP specification are syntax-based types, taken from
XML Schema.

The types of X12 and EDIFACT are somewhat more generic, but are still
syntax-based.

The types already defined in the CC document are a nice start for b), but as
has been observed, they need more work.

By the way, 'Ratio' is not defined, whereas 'Percent' is defined.  'Percent'
might be considered a special case of 'Ratio', else they should both be
provided.  Looks like there should also be a type of 'Pointer', to handle
URL's for example.

Mapping advice to convert ebXML data types to concrete syntax types may be
provided via class mappings.

Cheers,
         Bob

---Original Message-----
From: Mike Rawlins [mailto:rawlins@metronet.com]
Sent: Wednesday, March 28, 2001 12:05 PM
To: ebXML-core
Subject: Representation Types Alternatives


In my comments during the first review cycle I noted several problems
with representation types as they are currently defined.  I see these
problems as show stoppers that must be fixed before final approval.  The
1.02 documents seem to have few changes in this area.   I suggest that
the two most promising ways to handle my concerns are:

1)  Formally define representation types, refining the current
definitions

2)  Adopt an existing set of data types.  Several candidates exist:  The
most likely is the set identified in the BP Specification Schema,
section 9.1 - Data Typing.  Other choices are the datatypes defined in
XML schema or UML.

Before one or the other is adopted, a pertinent question to ask first is
what is the purpose of representation types?  If the purpose is to:

a)  merely constrain the value space ("set of values" is how it is
stated in the CC spec), then I suggest we take alternative 2 as the
simplest approach.  We may then define a set of primitive properties
such as quantity, amount, etc., that are reusable and may take the place
of some of the current representation types that would be dropped with
such an approach.

b)  If the purpose is to constrain the value space *and* provide the
analyst/modeler with a level of abstraction and higher level of
reusability than the types offered by the Specification Schema, XML, or
UML, then we should define a set of types rather than adopt one.  When
defining the set, we should fully specify all of the relevant fields for
each type (for example - measure has both value and units).

I tend to favor a) since it is simpler, can probably be done with less
effort, and more aligned with the BP and other work.

Regards,

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org