|
FYI Comment for BP Team
Mates.
Marcia McLure
----- Original Message -----
Sent: Monday, April 09, 2001 11:43 AM
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
>
|