RE: Core Component Analysis - SWIFT's Comments

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Bill,

I have submitted comments (directly to Karsten) addressing among other
things to the Datatype discussion.  I asked that these comments be exposed
when it was appropriate to do so.  I specifically did not want my comments
to become a show stopper in getting the document to public review.  

WRT Datatype, I would expect the document to address ebXML data types, which
might include a datatype 'DateTimeInstant' for example. that ebXML datatype
might well map to a specific XML Schema datatype.  ebXML probably would not
define a datatype 'Real'.  Of course it might(will?) include a datatype
'Amount' which when rendered in XML maps to a 'Real'.  The concrete mapping
of ebXML datatypes to XML datatypes is in my opinion a task for Core
Components to resolve.

When all of the concrete mappings from ebXML data types to XML datatypes are
defined, we may well find that some XML datatypes are not required to
support the defined ebXML datatypes.

Cheers,
        Bob Miller

-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: Wednesday, January 17, 2001 11:20 AM
To: ebXML Core
Subject: Re: Core Component Analysis - SWIFT's Comments


Nigel Wooden says "I  know we are 'syntax neutral' but I believe we
should provide an XML schema for each 'type' so that us poor users can
pick up standard representations for our data when developing business
documents for use in an ebXML environment..."

I think I know what Nigel means - i.e., if XML Schema provides a
datatype that seems to fit the bill for a basic core component -  like a
timeInstant, timeDuration or a float - then perhaps we should just go
ahead and use the standard datatype rather than "invent" our own.  Sure,
constraints and patterns might be applied to derivations of these basic
datatypes, but we may as well start with the fundamental data types
provided by the Schema recommendation.

In the meantime, I'm anxiously awaiting Bob Miller's comments on the
Datatype section.  Bob feels there's too much of that attitude of "if
it's in XML [Schema], we must want it."  I would've thought a standard
generic white-bread "float" Schema primitive datatype could serve as a
good base for really big quantities (e.g., as noted in
http://lists.ebxml.org/archives/ebxml-core/200101/msg00062.html, for
radioactivity measurements in Becquerels).  I can't imagine Bob
improving on what programmers pretty much expect of a floating point
number - but maybe he wants to bust out the mantissa and exponent as
separate core components.

And I'm used to thinking of a date as just a date, for which the XML
schema date datatype (ISO 8601) seems eminently suited. But this is
probably a minority opinion, as evidenced by the ebXML Trading-Partners'
Collaboration-Protocol Profile and Agreement Specification Version 0.1,
which insists in Section 7.1.9.2 - Dates - that "A date is expressed in
United States format, mm/dd/yyyy." See cpa-cpp-spec-0.1-interim.pdf at
http://lists.ebxml.org/archives/ebxml-tp/200101/msg00060.html. Forget
that XML Schema dates (CCYY-MM-DD) are sortable, or that their format
makes more sense to the rest of Christendom.  Like Ol' Blue Eyes, we
just have to do it "My Way."

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"