Hi All,
I've a problem with the Representation Types being consistent with the data
types of BP. My problem is that the data types of BP seem not to be
'business data representation types', but rather to be 'syntax data
representation types'. To understand the difference:
'Integer' is a syntax data representation type
''Amount' is a business data representation type (whose properties
may constrain the values to a syntax data representation type and range).
The degree to which a given representation can support constraints for a
given business data representation type is syntax dependent. The
constraints themselves need not be syntax dependent.
By the way, I've been trying to soak up the Data Consortium Namespace stuff
that John McClure has been touting. Of all the work I've seen to date on
business data representation, this is certainly the best I've seen.
Addressing business data communication needs of the Real Estate industry, it
takes a logical, object oriented approach to data organization. In my
opinion, this work (and the companion dictionary) is
must-read-and-understand material for those working on the representation of
business data in XML documents. This certainly includes some BP folks and
many CC folks. For those that missed John's reference to these documents, I
copy them below:
For the latest Data Consortium Namespace Specification, please see
http://www.dataconsortium.org/namespace/DCN150.DTD.pdf or
http://www.dataconsortium.org/namespace/DCN150.DTD.doc or
http://www.dataconsortium.org/namespace/DCN150.DTD.htm
For the latest Data Consortium Dictionary, please see
http://www.dataconsortium.org/namespace/DCD100.pdf or
http://www.dataconsortium.org/namespace/DCD100.xml (IE5)
Cheers,
Bob Miller
-----Original Message-----
From: Marcia L. McLure Ph.D. [mailto:[email protected]]
Sent: Monday, April 09, 2001 1:57 PM
To: [email protected]; '[email protected]'
Subject: Fw: Representation Types Alternatives
FYI Comment for BP Team Mates.
Marcia McLure
----- Original Message -----
From: CRAWFORD, Mark <mailto:[email protected]>
To: '[email protected]' <mailto:'[email protected]'> ; ebXML-core
<mailto:[email protected]>
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:[email protected]
<mailto:[email protected]> ]
> 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/ <http://www.metronet.com/~rawlins/>
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: [email protected]
>
> --
> Michael C. Rawlins, Rawlins EC Consulting
> http://www.metronet.com/~rawlins/ <http://www.metronet.com/~rawlins/>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: [email protected]
>
