OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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?



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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC