|
Margaret
Apologies! How could I have forgotten that we did, in
San Jose, take into account the list or representation terms from the UN/EDIFACT
MDRs as well as those from BSR and CALS.
However, as you rightly point out these have now been
updated and we should now take account of this as well whilst updating the ebXML
list.
Thanks
for the reminder.
best
regards
Sue
Sue Probert
Director, Document Engineering
Commerce One
Tel: +44 1332 342080
www.commerceone.com
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
>
|