RE: Representation Types Alternatives

["Probert, Sue" <Sue.Probert@commerceone.com>]

Mike

The work that we did last week in London was to check against ISO 11179 to
ensure that the CC set of representation types were correctly drawn from the
11179 list. ISO 11179 is a specification on which any implementation can be
based. The original CC list was drawn from a comparison between the ISO BSR
implementation of 11179 and the CALS implementation of 11179. A group
dedicated to this task at the San Jose meeting considered both these lists
and drew up a third list which became the agreed CC list by a consensus vote
in San Jose.

BTW I do not have a copy of 11179 as it is an extensive set of documents
which ISO like to be paid for! Like most other ISO docs it is rarely at hand
electronically. 

Following comments received during the first public review we checked these
against the ISO 11179 standard last week and we reckon that we found out
that there seemed to be some inconsistencies as neither CALS nor BSR
implementations of 11179 seem to have followed the standard completely. This
tidied up version will be included in the final CC deliverables. This still
needs final checking against the official 11179 source when we can get hold
of a copy.

As far as the relationship between the CC Representation Types and both the
Datatype list in the BP document and the Datatype list in the CC Context
Rules document is concerned we also tackled that question last week. They
are, of course, different things! The Representation Type List is included
in the CC NAming Conventions Document which is for naming and describing
SYNTAX NEUTRAL core components. They are NOT equivalent directly to the
Datatype list of any particular syntax, not even XML. However, it is
anticapated that there is indeed a need to clarify how the Datatypes of any
syntax, in which ebXML may be implemented, relate to the syntax neutral CCs.
In the BP and CC contect rules documents the Datatype Lists are included for
the BP Specification Schema and the Context Rules Engine both of which are
actually XML based tools.

Therefore, we believe that the consistency that is needed is in the mapping
of the XML Datatypes with the CC Representation Types i.e. defining how an
XML implementation will work in this regard. A table to provide this mapping
was developed last week and will be also included in the final version of
the CC document set.

regards

Sue

Sue Probert
Director, Document Engineering
Commerce One
Tel: +44 1332 342080
www.commerceone.com


-----Original Message-----
From: Blantz, Mary Kay [mailto:mblantz@netfish.com]
Sent: 10 April 2001 14:59
To: 'rawlins@metronet.com'
Cc: 'CRAWFORD, Mark'; ebXML-core
Subject: RE: Representation Types Alternatives


Hi Mike,

The document that you have does not have the latest list; the 
Editors and Hartmut worked on it last week.

You will find it in the next publication.

MK


-----Original Message-----
From: Mike Rawlins [mailto:rawlins@metronet.com]
Sent: Tuesday, April 10, 2001 9:49 AM
To: Blantz, Mary Kay
Cc: 'CRAWFORD, Mark'; ebXML-core
Subject: Re: Representation Types Alternatives


MK,

Thanks for the clarification, but that leaves me a bit confused.  I
fully support the decision to base the naming conventions on ISO 11179 -
that's not the issue for me.   I don't have a copy of that document, but
from the references I have found "Representation Classes" are part of
that document.  However, unless I'm mistaken, the specific
"representation types" that are referenced in the Naming Conventions
document are not.  I was told that the CC team developed this particular
set, and I believe that set is inadequate as it is currently specified.

Will someone who *does* have a copy of ISO 11179 please confirm for me
whether or not the specific set of representation types in the CC Naming
Conventions document does indeed come from ISO 111179?  If you can give
me the citation I will withdraw my objection.  However, that would still
leave the issue that the representation types of the CC Naming
Conventions and the data types of the BP modeling need to be harmonized
(I'm not saying *who* needs to change, just that they need to be brought
together ;^) ).

Mike

"Blantz, Mary Kay" wrote:

>  Last week the CC Editors worked on various areas, including
> Representation Types.  That is part of ourCC 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
> databeing sent.MKB
>
>      -----Original Message-----
>      From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org]
>      Sent: Monday, April 09, 2001 2:44 PM
>      To: 'rawlins@metronet.com'; ebXML-core
>      Subject: RE: Representation Types Alternatives
>
>      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
>      >
>
--
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