|
Mary Kay
You might like to know that the UN/EDIFACT Message
Design Rules Group used ISO 11179 as the basis for naming of UN/EDIFACT data
elements. They recently decided against the use of 'value' as a representation
term (though we originally thought that it was a good idea). The main reason was
that it did deviate from 11179. When we looked at the existing EDIFACT data
elements that had no other logical representation term other than value, we were
able to categorise them all by the addition of the following representation
terms:
age, date,
degree, measure, period, text and time
Did the London group look at the new MDR (Version 6
as approved at Washington EWG) when coming up with their latest list of
representation terms??
Margaret
----- Original Message -----
Sent: Tuesday, April 10, 2001 10:35
PM
Subject: RE: Representation Types
Alternatives
Last
week the CC Editors worked on various areas, including Representation
Types. That is part of our
CC
Naming Conventions document, and that team is led by Hartmut Hermes who was
with us in London.
We
agreed that the best choice would be to follow an approved standard:
11179. As far as I know,
the
only deviation was in the definition of 'value' which is commonly used to
describe the actual data
being sent.
MKB
Mike,
I believe the
Representation Types should be consistent with the data types of BP.
Conversely, BP data types should support those that are available in all
existing syntax specific instances of an ebXML document. For example,
if there are data types available in the W3C schema specification that are
missing from those of BP, then BP should be adjusted accordingly.
Mark Crawford
> -----Original Message-----
>
From: Mike Rawlins [mailto:rawlins@metronet.com]
> Sent: Monday, April 09, 2001 2:34 PM
> To: ebXML-core
> Subject: Re:
Representation Types Alternatives
>
>
> In the week since
I posted this only Bob Miller (for #1), and
>
Martin Bryan
> (who agrees with me on #2)
expressed any opinion (unless I'm missing
>
someone). Shall the editors be directed to make this change
> or does anyone
>
else have anything to say about it?
>
> Cheers,
>
> Mike
>
>
> Mike Rawlins
wrote:
>
> > 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
>
> --
> 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
>
|