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?

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/




[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